diff --git a/.agents/plugins/marketplace.json b/.agents/plugins/marketplace.json deleted file mode 100644 index 9e84cad8..00000000 --- a/.agents/plugins/marketplace.json +++ /dev/null @@ -1,192 +0,0 @@ -{ - "name": "productize-agent-skills", - "version": "1.1.2", - "metadata": { - "version": "1.1.2" - }, - "interface": { - "displayName": "Productize AI" - }, - "plugins": [ - { - "name": "productize-discovery", - "source": { - "source": "local", - "path": "./plugins/productize-discovery" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-strategy", - "source": { - "source": "local", - "path": "./plugins/productize-strategy" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-decision-making", - "source": { - "source": "local", - "path": "./plugins/productize-decision-making" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-growth", - "source": { - "source": "local", - "path": "./plugins/productize-growth" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-analytics", - "source": { - "source": "local", - "path": "./plugins/productize-analytics" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-finance", - "source": { - "source": "local", - "path": "./plugins/productize-finance" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-delivery", - "source": { - "source": "local", - "path": "./plugins/productize-delivery" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-design", - "source": { - "source": "local", - "path": "./plugins/productize-design" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-marketing", - "source": { - "source": "local", - "path": "./plugins/productize-marketing" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-operations", - "source": { - "source": "local", - "path": "./plugins/productize-operations" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-stakeholder-communication", - "source": { - "source": "local", - "path": "./plugins/productize-stakeholder-communication" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-ai-execution", - "source": { - "source": "local", - "path": "./plugins/productize-ai-execution" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-business-model", - "source": { - "source": "local", - "path": "./plugins/productize-business-model" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-venture-0-1", - "source": { - "source": "local", - "path": "./plugins/productize-venture-0-1" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - }, - { - "name": "productize-all", - "source": { - "source": "local", - "path": "./plugins/productize-all" - }, - "policy": { - "installation": "AVAILABLE", - "authentication": "ON_INSTALL" - }, - "category": "Productivity" - } - ] -} diff --git a/.agents/productize-runtime.json b/.agents/productize-runtime.json deleted file mode 100644 index e7d0b542..00000000 --- a/.agents/productize-runtime.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "generated": true, - "host": "codex", - "display_name": "OpenAI Codex", - "adapter_source": "hosts/codex.mjs", - "generated_skill_path": ".agents/skills/{skill}", - "sidecars": [ - { - "source": "bin/productize-artifact-log", - "install_name": "productize-artifact-log" - }, - { - "source": "bin/productize-completion-status", - "install_name": "productize-completion-status" - }, - { - "source": "bin/productize-config", - "install_name": "productize-config" - }, - { - "source": "bin/productize-context-restore", - "install_name": "productize-context-restore" - }, - { - "source": "bin/productize-context-save", - "install_name": "productize-context-save" - }, - { - "source": "bin/productize-registry-search", - "install_name": "productize-registry-search" - }, - { - "source": "bin/productize-routing.mjs", - "install_name": "productize-routing.mjs" - }, - { - "source": "bin/productize-runtime.mjs", - "install_name": "productize-runtime.mjs" - }, - { - "source": "bin/productize-session-log", - "install_name": "productize-session-log" - }, - { - "source": "bin/productize-skill-router", - "install_name": "productize-skill-router" - }, - { - "source": "bin/productize-update-check", - "install_name": "productize-update-check" - }, - { - "source": "bin/productize-workflow", - "install_name": "productize-workflow" - } - ] -} diff --git a/.agents/skills/productize-ab-test-analysis/SKILL.md b/.agents/skills/productize-ab-test-analysis/SKILL.md deleted file mode 100644 index ab7c3203..00000000 --- a/.agents/skills/productize-ab-test-analysis/SKILL.md +++ /dev/null @@ -1,165 +0,0 @@ ---- -name: productize-ab-test-analysis -description: >- - A/B Test Analysis. Use when evaluating A/B test results, checking statistical significance, - validating sample size, reading confidence intervals, or deciding whether to ship, extend, - or stop an experiment. ---- - - - -# A/B Test Analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ab-test-analysis` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: A/B test decision memo with statistical readout and ship, extend, or stop recommendation - -Use when evaluating A/B test results, checking statistical significance, validating sample size, reading confidence intervals, or deciding whether to ship, extend, or stop an experiment. - -## Productize Contract - -- **Primary lifecycle**: Measure -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: A/B test decision memo with statistical readout and ship, extend, or stop recommendation -- **Source method**: pm-skills-main/pm-data-analytics/skills/ab-test-analysis/SKILL.md - -## Method - -## A/B Test Analysis - -Evaluate A/B test results with statistical rigor and translate findings into clear product decisions. - -### Context - -You are analyzing A/B test results for **$ARGUMENTS**. - -If the user provides data files (CSV, Excel, or analytics exports), read and analyze them directly. Generate Python scripts for statistical calculations when needed. - -### Instructions - -1. **Understand the experiment**: - - What was the hypothesis? - - What was changed (the variant)? - - What is the primary metric? Any guardrail metrics? - - How long did the test run? - - What is the traffic split? - -2. **Validate the test setup**: - - **Sample size**: Is the sample large enough for the expected effect size? - - Use the formula: n = (Z2/2 x 2 x p x (1-p)) / MDE2 - - Flag if the test is underpowered (<80% power) - - **Duration**: Did the test run for at least 1-2 full business cycles? - - **Randomization**: Any evidence of sample ratio mismatch (SRM)? - - **Novelty/primacy effects**: Was there enough time to wash out initial behavior changes? - -3. **Calculate statistical significance**: - - **Conversion rate** for control and variant - - **Relative lift**: (variant - control) / control x 100 - - **p-value**: Using a two-tailed z-test or chi-squared test - - **Confidence interval**: 95% CI for the difference - - **Statistical significance**: Is p < 0.05? - - **Practical significance**: Is the lift meaningful for the business? - - If the user provides raw data, generate and run a Python script to calculate these. - -4. **Check guardrail metrics**: - - Did any guardrail metrics (revenue, engagement, page load time) degrade? - - A winning primary metric with degraded guardrails may not be a true win - -5. **Interpret results**: - - | Outcome | Recommendation | - |---|---| - | Significant positive lift, no guardrail issues | **Ship it** -- roll out to 100% | - | Significant positive lift, guardrail concerns | **Investigate** -- understand trade-offs before shipping | - | Not significant, positive trend | **Extend the test** -- need more data or larger effect | - | Not significant, flat | **Stop the test** -- no meaningful difference detected | - | Significant negative lift | **Don't ship** -- revert to control, analyze why | - -6. **Provide the analysis summary**: - ``` - ## A/B Test Results: [Test Name] - - **Hypothesis**: [What we expected] - **Duration**: [X days] | **Sample**: [N control / M variant] - - | Metric | Control | Variant | Lift | p-value | Significant? | - |---|---|---|---|---|---| - | [Primary] | X% | Y% | +Z% | 0.0X | Yes/No | - | [Guardrail] | ... | ... | ... | ... | ... | - - **Recommendation**: [Ship / Extend / Stop / Investigate] - **Reasoning**: [Why] - **Next steps**: [What to do] - ``` - -Think step by step. Save as markdown. Generate Python scripts for calculations if raw data is provided. - ---- - -### Further Reading - -- [A/B Testing 101 + Examples](https://www.productcompass.pm/p/ab-testing-101-for-pms) -- [Testing Product Ideas: The Ultimate Validation Experiments Library](https://www.productcompass.pm/p/the-ultimate-experiments-library) -- [Are You Tracking the Right Metrics?](https://www.productcompass.pm/p/are-you-tracking-the-right-metrics) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-analyze-feature-requests/SKILL.md b/.agents/skills/productize-analyze-feature-requests/SKILL.md deleted file mode 100644 index 29a26d34..00000000 --- a/.agents/skills/productize-analyze-feature-requests/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: productize-analyze-feature-requests -description: >- - Analyze Feature Requests. Use when reviewing customer, sales, support, or stakeholder - feature requests and turning them into prioritized product decisions. ---- - - - -# Analyze Feature Requests - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `analyze-feature-requests` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Feature-request triage report with themes, strategic fit, effort/risk, and backlog recommendations - -Use when reviewing customer, sales, support, or stakeholder feature requests and turning them into prioritized product decisions. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: Discover -- **Primary artifact**: Feature-request triage report with themes, strategic fit, effort/risk, and backlog recommendations -- **Source method**: pm-skills-main/pm-product-discovery/skills/analyze-feature-requests/SKILL.md - -## Method - -## Analyze Feature Requests - -Categorize, evaluate, and prioritize customer feature requests against product goals. - -### Context - -You are analyzing feature requests for **$ARGUMENTS**. - -If the user provides files (spreadsheets, CSVs, or documents with feature requests), read and analyze them directly. If data is in a structured format, consider creating a summary table. - -### Domain Context - -Never allow customers to design solutions. Prioritize **opportunities (problems)**, not features. Use **Opportunity Score** (Dan Olsen) to evaluate customer-reported problems: Opportunity Score = Importance x (1 Satisfaction), normalized to 0-1. See the `prioritization-frameworks` skill for full details and templates. - -### Instructions - -The user will describe their product goal and provide feature requests. Work through these steps: - -1. **Understand the goal**: Confirm the product objective and desired outcomes that will guide prioritization. - -2. **Categorize requests into themes**: Group related requests together and name each theme. - -3. **Assess strategic alignment**: For each theme, evaluate how well it aligns with the stated goals. - -4. **Prioritize the top 3 features** based on: - - **Impact**: Customer value and number of users affected - - **Effort**: Development and design resources required - - **Risk**: Technical and market uncertainty - - **Strategic alignment**: Fit with product vision and goals - -5. **For each top feature**, provide: - - Rationale (customer needs, strategic alignment) - - Alternative solutions worth considering - - High-risk assumptions - - How to test those assumptions with minimal effort - -Think step by step. Save as markdown or create a structured output document. - ---- - -### Further Reading - -- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-beachhead-segment/SKILL.md b/.agents/skills/productize-beachhead-segment/SKILL.md deleted file mode 100644 index 9a94e6f4..00000000 --- a/.agents/skills/productize-beachhead-segment/SKILL.md +++ /dev/null @@ -1,226 +0,0 @@ ---- -name: productize-beachhead-segment -description: >- - Beachhead Segment. Use when choosing the first market segment, entry wedge, launch audience, - early ICP, or 0-to-1 customer focus. ---- - - - -# Beachhead Segment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `beachhead-segment` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Beachhead segment decision brief with scoring, wedge rationale, and expansion path - -Use when choosing the first market segment, entry wedge, launch audience, early ICP, or 0-to-1 customer focus. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: Growth -- **Primary artifact**: Beachhead segment decision brief with scoring, wedge rationale, and expansion path -- **Source method**: pm-skills-main/pm-go-to-market/skills/beachhead-segment/SKILL.md - -## Method - -## Overview -Identify the first beachhead market segment for product launch. This skill evaluates potential market segments against key criteria to find your initial winning segment that enables fast PMF validation and adjacent expansion. - -## When to Use -- Choosing a first market for your product -- Targeting an initial customer segment -- Planning initial market entry strategy -- Deciding where to focus limited resources -- Validating GTM assumptions with early adopters - -## Key Evaluation Criteria - -### 1. Burning Pain Point -Does this segment experience an acute, unmet problem? -- Daily frustration with the status quo -- Significant productivity loss or cost impact -- Emotional urgency to find a solution -- Current workarounds are expensive or fragile -- Problem is getting worse over time - -### 2. Willingness to Pay -Does this segment have budget and motivation to pay for a solution? -- Documented budget allocation for this problem area -- ROI is clear and compelling (value > cost) -- Economic impact of problem justifies solution cost -- Decision-maker has autonomy or influence over budget -- No free or DIY alternatives that fully satisfy need - -### 3. Winnable Market Share -Can you realistically capture 60-70% of this segment in 3-18 months? -- Segment is large enough but not oversaturated -- Limited competition or easy differentiation -- Market players are fragmented or complacent -- Your product has clear competitive advantage -- You have unique access or distribution advantage - -### 4. Referral Potential -Will customers naturally refer or recommend to others? -- Segment contains professional communities -- Customers interact with adjacent segments (expansion opportunity) -- High word-of-mouth culture in this industry -- Network effects within the segment -- Solving problem for one creates demand in adjacent segments - -## How It Works - -### Step 1: List Potential Segments -Brainstorm all possible target segments: -- Industry verticals (SaaS, healthcare, manufacturing, etc.) -- Company size (SMB, mid-market, enterprise) -- Job titles or roles -- Geographic regions -- Use cases or use-case variations -- Customer maturity level - -### Step 2: Research Pain Points -Validate burning pain in each segment: -- Customer interviews and discovery calls -- Problem validation through surveys -- Market research and analyst reports -- Competitor positioning and customer reviews -- Quantify cost/impact of the problem -- Identify current workarounds and limitations - -### Step 3: Assess Willingness to Pay -Determine budget and economic viability: -- Segment's budget for this problem category -- ROI calculation (value gained vs cost) -- Current spending on solutions or workarounds -- Budget decision-making process -- Typical deal size expectations -- Pricing sensitivity in the segment - -### Step 4: Evaluate Winnability -Assess realistic market share potential: -- Total addressable market (TAM) size -- Competitive landscape and positioning -- Your differentiation or unfair advantage -- Distribution access to this segment -- Time and resources required -- Market growth and momentum - -### Step 5: Identify Referral Pathways -Map expansion opportunities: -- Adjacent segments that reference segment influences -- Network effects within the segment -- Professional communities and associations -- Customer-to-customer recommendations -- Natural expansion path to adjacent markets -- Viral or network effects from solving core pain - -### Step 6: Select Beachhead -Choose your primary launch segment: -- Highest combined score across four criteria -- Most achievable for your current resources -- Shortest path to PMF and revenue -- Best reference for adjacent expansion -- Most enthusiastic early customer cohort - -## Input Format -Use $ARGUMENTS to pass: -- Product description and capabilities -- Initial market research and validation data -- Potential segment options -- Constraints and limitations -- Timeline and resource constraints -- Current customer data or feedback - -## Output -A beachhead segment analysis including: -- Top 3-5 recommended segments with scoring -- Primary beachhead segment recommendation -- Pain point validation and evidence -- Willingness to pay assessment and pricing guidance -- Realistic market share and revenue projections -- Referral and expansion pathways to adjacent segments -- 90-day customer acquisition plan for beachhead -- Post-beachhead expansion roadmap - -## Framework -Based on Geoffrey Moore's beachhead market strategy in "Crossing the Chasm." Focuses on finding the smallest winnable, referenceable market that validates PMF and enables expansion. - -## Tips -- Start absurdly specific. A niche beachhead is better than a vague mass market -- Choose the segment most likely to evangelize your solution -- Validate all four criteria with at least 10 customer interviews -- Select segment with fastest path to revenue and references -- Ensure beachhead can reference to adjacent market segments -- Focus all resources on dominating the beachhead (not diluting efforts) -- Plan exit from beachhead only after 60%+ market share - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-behavioral-guidelines/SKILL.md b/.agents/skills/productize-behavioral-guidelines/SKILL.md deleted file mode 100644 index 4539caf3..00000000 --- a/.agents/skills/productize-behavioral-guidelines/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: productize-behavioral-guidelines -description: >- - Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or - refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and - define verifiable success criteria. ---- - - - -# Behavioral Guidelines - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `behavioral-guidelines` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Behavioral Guidelines UX/design review with findings, constraints, fixes, and acceptance checks - -Behavioral guidelines to reduce common LLM coding mistakes on LLM coding pitfalls. - -**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment. - -## 1. Think Before Coding - -**Do not assume. Do not hide confusion. Surface tradeoffs.** - -Before implementing: -- State your assumptions explicitly. If uncertain, ask. -- If multiple interpretations exist, present them instead of picking silently. -- If a simpler approach exists, say so. Push back when warranted. -- If something is unclear, stop. Name what is confusing. Ask. - -## 2. Simplicity First - -**Minimum code that solves the problem. Nothing speculative.** - -- No features beyond what was asked. -- No abstractions for single-use code. -- No flexibility or configurability that was not requested. -- No error handling for impossible scenarios. -- If you write 200 lines and it could be 50, rewrite it. - -Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. - -## 3. Surgical Changes - -**Touch only what you must. Clean up only your own mess.** - -When editing existing code: -- Do not improve adjacent code, comments, or formatting. -- Do not refactor things that are not broken. -- Match existing style, even if you would do it differently. -- If you notice unrelated dead code, mention it instead of deleting it. - -When your changes create orphans: -- Remove imports, variables, functions, and files that your changes made unused. -- Do not remove pre-existing dead code unless asked. - -The test: Every changed line should trace directly to the user's request. - -## 4. Goal-Driven Execution - -**Define success criteria. Loop until verified.** - -Transform tasks into verifiable goals: -- "Add validation" -> "Write tests for invalid inputs, then make them pass." -- "Fix the bug" -> "Write a test that reproduces it, then make it pass." -- "Refactor X" -> "Ensure tests pass before and after." - -For multi-step tasks, state a brief plan: - -```text -1. [Step] -> verify: [check] -2. [Step] -> verify: [check] -3. [Step] -> verify: [check] -``` - -Strong success criteria let you loop independently. Weak criteria such as "make it work" require constant clarification. diff --git a/.agents/skills/productize-business-model-design/SKILL.md b/.agents/skills/productize-business-model-design/SKILL.md deleted file mode 100644 index e15d9cbc..00000000 --- a/.agents/skills/productize-business-model-design/SKILL.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -name: productize-business-model-design -description: >- - Design, compare, or document business models using the right canvas for the situation. Use - when a founder, product team, strategist, or innovation team asks to fill a business model - canvas, lean canvas, platform canvas, value creation and capture model, revenue/cost logic, - customer/user/payer model, or variants of "what is the business model", "how does this make - money", "which canvas should I use", "turn this idea into a business model", or "compare - these business models". ---- - - - -# Business Model Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `business-model-design` -- **Lifecycle**: Strategize -- **Category**: Business Model -- **Primary artifact**: Business Model Design business-model memo with value capture logic, risks, and next tests - -Create a working business model artifact, not a generic strategy essay. A business -model describes how an organization creates, delivers, and captures value. - -## Argument Hint - -`` - -## Usage - -```text -/business-model-design $ARGUMENTS -``` - -## Core Rule - -Choose the canvas based on the user's situation, then produce a filled-in canvas with -clear assumptions, open questions, and validation priorities. - -Load `references/canvas-selection.md` when choosing between canvas types. - -Load `references/canvas-templates.md` before creating blank templates, filled-in -canvases, visual layouts, tables, or printable artifacts. It contains the canonical -field labels for the standard, lean, and platform canvases. - -Load `references/business-model-output-rules.md` when comparing models, creating -handoff-ready outputs, or translating a canvas into experiments. - -Use the matching `assets/*.html` file when the user asks for a printable, visual, or -browser-openable canvas: - -- `assets/standard-business-model-canvas.html` -- `assets/lean-business-model-canvas.html` -- `assets/platform-business-model-canvas.html` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `business model canvas`, `bmc`, `all modes`, `value proposition mode`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Identify the Business Model Context - -Determine: - -- Existing company, new venture, corporate startup, platform, or sustainability - redesign. -- Customer, user, buyer, payer, producer, consumer, owner, and partner roles. -- What value is created, for whom, how it is delivered, and how value is captured. -- Whether the user wants a blank template, a filled canvas, a critique, or a - before/after redesign. - -If the user only gives a product or technology, ask what customer/user problem it -addresses before filling the model. - -### 2. Select the Canvas - -- **Standard Business Model Canvas**: use for most companies and product/service - business models. -- **Lean Business Model Canvas**: use for early-stage ventures, corporate startups, - unknown markets, and concepts that need problem/solution/risk validation. -- **Platform Business Model Canvas**: use for multi-sided platforms, marketplaces, - ecosystems, and models where several stakeholder groups exchange value. - -If two canvases apply, pick the primary one and add a short note showing what the -secondary lens would reveal. - -### 3. Fill the Canvas - -For each field: - -- Write concrete content, not slogans. -- Separate known facts from assumptions. -- Name the stakeholder explicitly. -- Link revenue streams to payer behavior and costs to required activities/resources. -- Avoid product-centric framing when the field should describe a customer need, - transaction, or job. - -### 4. Test Internal Coherence - -Check: - -- Does the value proposition match the customer segment and channel? -- Are key activities/resources/partners sufficient to deliver the value proposition? -- Does revenue logic match who receives value and who pays? -- Does the cost structure reflect the actual operating model? -- For platforms, are value transactions balanced for all sides? -- For lean canvases, are the highest-risk assumptions visible and testable? - -### 5. Produce the Output - -Default output: - -1. **Canvas selection** with rationale. -2. **Filled canvas** in editable Markdown table form. -3. **Coherence check**: strongest fit, weakest link, hidden assumption. -4. **Validation priorities**: 3-5 experiments or evidence gaps. -5. **Next decision**: what the team should decide or test next. - -## Output Rules - -- Preserve the exact canvas field labels from `references/canvas-templates.md`. -- Do not rename canvas fields unless the user asks for a custom artifact. -- Do not copy long source passages. Use canonical labels and original analysis. -- If facts are missing, mark them as assumptions rather than inventing them. -- When creating a visual or printable canvas, keep the same field structure as the - matching template. -- Do not reproduce branded poster/trade-dress artwork from source PDFs. Use the clean - bundled templates and preserve the operational structure. diff --git a/.agents/skills/productize-business-model-design/references/pm-skills-main-merge.md b/.agents/skills/productize-business-model-design/references/pm-skills-main-merge.md deleted file mode 100644 index d4791598..00000000 --- a/.agents/skills/productize-business-model-design/references/pm-skills-main-merge.md +++ /dev/null @@ -1,140 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to strengthen Business Model Canvas coverage and mode switching between BMC, Lean Canvas, Startup Canvas, and Value Proposition views. - -## Routing Signals - -- business model canvas -- bmc -- all modes -- value proposition mode - -## pm-product-strategy/skills/business-model/SKILL.md - -## Metadata -- **Name**: business-model -- **Description**: Generate a Business Model Canvas with all 9 building blocks. Use when creating a business model, documenting how a business creates value, or analyzing an existing business model. -- **Triggers**: business model canvas, BMC, business model, how we make money - -## Instructions - -You are a business model strategist designing a Business Model Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Business Model Canvas that outlines how the business creates, delivers, and captures value. - -## Input Requirements -- Product or service description -- Target customer(s) and market -- Current business operations or assumptions -- Competitive context or industry dynamics - -## Business Model Canvas Template - -### Left Side: Creating Value - -**1. Key Partners** -- Who are the key strategic partners and suppliers? -- What partnerships enable our business model? -- Which activities do partners handle? -- Are there joint ventures or co-creation opportunities? - -**2. Key Activities** -- What key activities does the business perform? -- What processes are critical to delivering value? -- Are these activities in-house or outsourced? -- Production, problem-solving, platform/network activities? - -**3. Key Resources** -- What resources are necessary to create value? -- Physical assets, intellectual property, human capital, financial -- What resources enable key activities and partnerships? -- What's the minimum viable resource set? - -### Center: The Value Proposition - -**4. Value Propositions** -- What value do we deliver to customers? -- Which customer problems do we solve? -- What needs are satisfied? -- What products/services address each segment? -- Quantitative (price, speed, quality) vs. qualitative (design, status) - -### Right Side: Delivering Value - -**5. Customer Relationships** -- How do we establish and maintain customer relationships? -- Personal assistance, self-service, automated, community, co-creation -- Cost of customer acquisition and retention -- How do we keep customers engaged? - -**6. Channels** -- How do customers discover and access the value? -- Awareness: How do customers learn about us? -- Purchase: How do they buy? -- Delivery: How is value delivered? -- After-sales: How do we support customers? -- Direct vs. indirect, owned vs. partner channels - -**7. Customer Segments** -- Who are the key customer segments? -- Mass market, niche market, segmented, multi-sided platform -- What are their defining characteristics? -- Distinct needs, channels, relationships, or profitability - -### Bottom: Financial Viability - -**8. Cost Structure** -- What are the most important costs? -- Fixed vs. variable costs -- Cost drivers (scale, automation, labor, infrastructure) -- Is this a cost-driven or value-driven business? - -**9. Revenue Streams** -- How does the business make money? -- Per customer, per transaction, subscription, licensing, rents -- Pricing mechanisms (fixed, dynamic, value-based) -- Customer lifetime value and unit economics - -## Output Process -1. Identify and profile customer segments -2. Define the core value proposition(s) -3. Map customer relationships and channels -4. List key activities and resources -5. Identify key partners -6. Outline cost structure -7. Define revenue streams -8. Ensure all 9 blocks align and support each other -9. Test economic viability (LTV > 3x CAC) -10. Identify key assumptions and risks - -### Domain Context - -**Business Model Canvas vs Lean Canvas vs Startup Canvas**: - -Business Model Canvas (Strategyzer, Alexander Osterwalder) is the most widely used canvas framework. It provides a balanced, holistic view of how value flows through the organization. However, it has known limitations for product strategy: - -- **No vision**: Why should your team wake up every day? BMC doesn't address motivation or aspiration. -- **No Can't/Won't test**: What stops competitors from copying you? BMC lacks a defensibility section that goes beyond listing resources. -- **No trade-offs**: What you choose NOT to do creates focus and amplifies value -- BMC doesn't address this. -- **No key metrics**: How do you know the strategy is working? BMC has no metrics section. -- **Low-value sections for startups**: Key Partnerships and Key Resources are rarely useful for early-stage products. - -**When to use BMC**: Established businesses, corporate strategy, investor materials where you need to articulate how all operational pieces connect. - -**Alternatives**: -- **Lean Canvas** (Ash Maurya): Startup-focused, faster, replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. Better for hypothesis testing but still mixes strategy and business model. -- **Startup Canvas** (Pawe Huryn): Separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended for new products where you need strategic clarity alongside the business model. - -## Notes -- The Business Model Canvas provides a holistic view of how value flows through the organization -- Each block should reinforce and support the others -- Strong business models have clear, defensible value propositions -- Financial sustainability requires revenue to exceed costs at scale -- Use this to identify opportunities for innovation and optimization - ---- - -### Further Reading - -- [Business Model Canvas Examples: Google Maps, Airbnb, Uber](https://www.productcompass.pm/p/business-model-canvas-examples) -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) diff --git a/.agents/skills/productize-cohort-analysis/SKILL.md b/.agents/skills/productize-cohort-analysis/SKILL.md deleted file mode 100644 index e847b52c..00000000 --- a/.agents/skills/productize-cohort-analysis/SKILL.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -name: productize-cohort-analysis -description: >- - Cohort Analysis. Use when analyzing retention by signup, activation, usage, plan, feature - adoption, or customer segment, especially when churn, engagement, or product health needs - cohort evidence. ---- - - - -# Cohort Analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `cohort-analysis` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Cohort retention and engagement diagnosis with segment-level actions - -Use when analyzing retention by signup, activation, usage, plan, feature adoption, or customer segment, especially when churn, engagement, or product health needs cohort evidence. - -## Productize Contract - -- **Primary lifecycle**: Measure -- **Supporting lifecycle**: Growth -- **Primary artifact**: Cohort retention and engagement diagnosis with segment-level actions -- **Source method**: pm-skills-main/pm-data-analytics/skills/cohort-analysis/SKILL.md - -## Method - -## Purpose -Analyze user engagement and retention patterns by cohort to identify trends in user behavior, feature adoption, and long-term engagement. Combine quantitative insights with qualitative research recommendations. - -## How It Works - -### Step 1: Read and Validate Your Data -- Accept CSV, Excel, or JSON data files with user cohort information -- Verify data structure: cohort identifier, time periods, engagement metrics -- Check for missing values and data quality issues -- Summarize key statistics (cohort sizes, date ranges, metrics available) - -### Step 2: Generate Quantitative Analysis -- Calculate cohort retention rates and engagement trends -- Identify retention curves, drop-off patterns, and anomalies -- Compute feature adoption rates across cohorts -- Calculate month-over-month or period-over-period changes -- Generate Python analysis scripts using pandas and numpy if requested - -### Step 3: Create Visualizations -- Generate retention heatmaps (cohorts vs. time periods) -- Create line charts showing cohort progression -- Build comparison charts for feature adoption -- Visualize drop-off points and engagement trends -- Output as interactive charts or static images - -### Step 4: Identify Insights & Patterns -- Spot one or more significant patterns: - - Early churn in specific cohorts - - Late-stage engagement changes - - Feature adoption clusters - - Seasonal or temporal trends -- Highlight surprising findings and deviations -- Compare cohort performance to establish baselines - -### Step 5: Suggest Follow-Up Research -- Recommend qualitative research methods: - - Targeted user interviews with churning users - - Feature usage surveys with engaged cohorts - - Session replays of key interaction patterns - - Win/loss analysis for high vs. low retention cohorts -- Design follow-up quantitative studies -- Suggest A/B tests or feature experiments - -## Usage Examples - -**Example 1: Upload CSV Data** -``` -Upload cohort_engagement.csv with columns: cohort_month, weeks_active, -user_id, feature_x_usage, engagement_score - -Request: "Analyze retention patterns and identify why Q4 2025 cohorts -underperform compared to Q3" -``` - -**Example 2: Describe Data Format** -``` -"I have monthly user cohorts from Jan-Dec 2025. Each row shows: -cohort date, user ID, purchase frequency, and support tickets. -Analyze which cohorts show best long-term retention." -``` - -**Example 3: Feature Adoption Analysis** -``` -Upload feature_usage.xlsx with cohort adoption data. - -Request: "Compare adoption curves for our new feature across cohorts. -Which cohorts adopted fastest? Any patterns?" -``` - -## Key Capabilities - -- **Data Reading**: Import CSV, Excel, JSON, SQL query results -- **Retention Analysis**: Calculate and visualize retention rates over time -- **Cohort Comparison**: Compare metrics across cohort groups -- **Anomaly Detection**: Flag unusual patterns or drop-offs -- **Python Scripts**: Generate reusable analysis code for ongoing analysis -- **Visualizations**: Create heatmaps, charts, and interactive dashboards -- **Research Design**: Suggest targeted follow-up studies and interview approaches -- **Statistical Summary**: Provide quantitative metrics and correlation analysis - -## Tips for Best Results - -1. **Include time dimension**: Provide data across multiple time periods -2. **Define cohort clearly**: Make cohort grouping explicit (signup month, feature launch date, etc.) -3. **Provide context**: Explain product changes, launches, or events during the period -4. **Multiple metrics**: Include retention, engagement, feature usage, revenue, etc. -5. **Sufficient data**: At least 3-4 cohorts for meaningful pattern identification -6. **Request specific output**: Ask for visualizations, Python scripts, or research recommendations - -## Output Format - -You'll receive: -- **Data Summary**: Cohort overview and data quality assessment -- **Quantitative Findings**: Key metrics, retention rates, and trend analysis -- **Visualizations**: Charts showing retention curves, adoption patterns -- **Pattern Identification**: 2-3 significant insights from the data -- **Research Recommendations**: Specific qualitative and quantitative follow-ups -- **Analysis Scripts** (if requested): Python code for reproducible analysis -- **Next Steps**: Prioritized actions based on findings - ---- - -### Further Reading - -- [Cohort Analysis 101: How to Reduce Churn and Make Better Product Decisions](https://www.productcompass.pm/p/cohort-analysis) -- [The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs](https://www.productcompass.pm/p/the-product-analytics-playbook-aarrr) -- [Are You Tracking the Right Metrics?](https://www.productcompass.pm/p/are-you-tracking-the-right-metrics) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-competitive-brief/SKILL.md b/.agents/skills/productize-competitive-brief/SKILL.md deleted file mode 100644 index d8c40d58..00000000 --- a/.agents/skills/productize-competitive-brief/SKILL.md +++ /dev/null @@ -1,446 +0,0 @@ ---- -name: productize-competitive-brief -description: >- - Create a competitive analysis brief for one or more competitors or a feature area. Use when - informing product strategy or feature prioritization, building sales battle cards, prepping - board or investor materials, or deciding where to differentiate versus achieve parity. ---- - - - -# Competitive Brief - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `competitive-brief` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Competitive Brief strategy memo with choices, tradeoffs, risks, and recommended next move - -Create a competitive analysis brief for one or more competitors or a feature area. - -## Argument Hint - -`` - -## Usage - -```text -/competitive-brief $ARGUMENTS -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `competitive battlecard`, `sales battlecard`, `objection handling`, `win loss`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Scope the Analysis - -Ask the user: -- **Competitor(s)**: Which specific competitor(s) to analyze? Or a feature area to compare across competitors? -- **Focus**: Full product comparison, specific feature area, pricing/packaging, go-to-market, or positioning? -- **Context**: What decision will this inform? Product strategy, sales enablement, investor/board materials, or feature prioritization? - -### 2. Research - -Use web research when available: -- Product pages and feature lists -- Pricing pages and packaging -- Recent product launches, blog posts, and changelogs -- Press coverage and analyst reports -- Customer reviews and ratings from G2, Capterra, TrustRadius, or similar sources -- Job postings as signals of strategic direction -- Social media and community discussions - -If a knowledge base is connected: -- Search for existing competitive analysis documents -- Find win/loss reports or sales battle cards -- Pull prior competitive research - -If chat is connected: -- Search for competitive mentions in sales or product channels -- Find recent deal feedback involving competitors - -### 3. Generate the Brief - -#### Competitor Overview - -For each competitor: -- Company summary: founding, size, funding/revenue if public, target market -- Product positioning: how they describe themselves, who they target -- Recent momentum: launches, funding, partnerships, customer wins - -#### Feature Comparison - -Compare capabilities across key areas relevant to the analysis. Use the feature comparison matrix guidance below for rating scales and templates. - -#### Positioning Analysis - -Analyze how each competitor positions themselves: target customer, category claim, key differentiator, and value proposition. Use the positioning statement template and message architecture levels below. - -#### Strengths and Weaknesses - -For each competitor: -- **Strengths**: Where they genuinely excel. What customers praise. -- **Weaknesses**: Where they fall short. What customers complain about. -- Be honest and evidence-based. Do not dismiss competitors or inflate their weaknesses. - -#### Opportunities - -Based on the analysis: -- Where are there gaps in competitor offerings we could exploit? -- What are customers asking for that no one provides well? -- Where are competitors making bets we disagree with? -- What market shifts could advantage our approach? - -#### Threats - -- Where are competitors investing heavily? -- What competitive moves could disrupt our position? -- Where are we most vulnerable? -- What would a nightmare-scenario competitive move look like? - -#### Strategic Implications - -Tie the analysis back to product strategy: -- What should we build, accelerate, or deprioritize based on this analysis? -- Where should we differentiate versus achieve parity? -- How should we adjust positioning or messaging? -- What should we monitor going forward? - -### 4. Follow Up - -After generating the brief: -- Ask if the user wants to dive deeper on any section -- Offer to create a one-page summary for executives -- Offer to create sales battle cards for competitive deals -- Offer to draft a "how to win against [competitor]" guide -- Offer to set up a monitoring plan for competitive moves - -## Competitive Landscape Mapping - -### Identifying the Competitive Set - -Define competitors at multiple levels: - -**Direct competitors**: Products that solve the same problem for the same users in the same way. -- These are the products your customers actively evaluate against you. -- They appear in deals, customer comparisons, and review-site matchups. - -**Indirect competitors**: Products that solve the same problem differently. -- Different approach to the same user need, such as spreadsheets versus a dedicated project management tool. -- Include non-consumption: sometimes the competitor is doing nothing or using a manual process. - -**Adjacent competitors**: Products that do not compete today but could. -- Companies with similar technology, customer base, or distribution that could expand into your space. -- Larger platforms that could add your functionality as a feature. -- Startups attacking a niche that could grow into your core market. - -**Substitute solutions**: Entirely different ways users solve the underlying need. -- Hiring a person instead of buying software. -- Using a general-purpose tool such as Excel or email instead of a specialized one. -- Outsourcing the process entirely. - -### Landscape Map - -Position competitors on meaningful dimensions: - -Common axes: -- Breadth versus depth: suite versus point solution -- SMB versus enterprise: market segment focus -- Self-serve versus sales-led: go-to-market approach -- Simple versus powerful: product complexity -- Horizontal versus vertical: general purpose versus industry-specific - -Choose axes that reveal strategic positioning differences relevant to your market. The right axes make competitive dynamics visible. - -### Monitoring the Landscape - -Track competitive movements over time: -- Product launches and feature releases: changelogs, blog posts, press releases -- Pricing and packaging changes -- Funding rounds and acquisitions -- Key hires and job postings -- Customer wins and losses, especially your wins/losses -- Analyst and review coverage -- Partnership announcements - -## Feature Comparison Matrices - -### Building a Feature Comparison - -1. Define capability areas: Group features into functional categories that matter to buyers, not your internal architecture. Use the categories buyers use when evaluating. -2. List specific capabilities: Under each area, list the specific features or capabilities to compare. -3. Rate each competitor: Use a consistent rating scale. - -### Rating Scale Options - -Simple, recommended for most cases: -- Strong: Market-leading capability. Deep functionality, well-executed. -- Adequate: Functional capability. Gets the job done but is not differentiated. -- Weak: Exists but limited. Significant gaps or poor execution. -- Absent: Does not have this capability. - -Detailed, for deep-dive comparisons: -- 5: Best in class. Defines the standard others aspire to. -- 4: Strong. Fully featured and well-executed. -- 3: Adequate. Meets basic needs without differentiation. -- 2: Limited. Exists but with significant gaps. -- 1: Minimal. Barely functional or in early beta. -- 0: Absent. Not available. - -### Comparison Matrix Template - -```text -| Capability Area | Our Product | Competitor A | Competitor B | -|----------------|-------------|-------------|-------------| -| [Area 1] | | | | -| [Feature 1] | Strong | Adequate | Absent | -| [Feature 2] | Adequate | Strong | Weak | -| [Area 2] | | | | -| [Feature 3] | Strong | Strong | Adequate | -``` - -### Tips for Feature Comparison - -- Rate based on real product experience, customer feedback, and reviews, not just marketing claims. -- Features exist on a spectrum. "Has feature X" is less useful than "How well does it do X?" -- Weight the comparison by what matters to target customers, not by total feature count. -- Update regularly because feature comparisons get stale fast. -- Be honest about where competitors are ahead. A comparison that always shows us winning is not credible. -- Include why each capability area matters. Not all features matter equally to buyers. - -## Positioning Analysis Frameworks - -### Positioning Statement Analysis - -For each competitor, extract their positioning: - -Template: For [target customer] who [need/problem], [Product] is a [category] that [key benefit]. Unlike [competitor/alternative], [Product] [key differentiator]. - -Sources for positioning: -- Homepage headline and subheadline -- Product description on app stores or review sites -- Sales pitch decks if available from prospects or public materials -- Analyst briefing materials -- Earnings call language for public companies - -### Message Architecture Analysis - -How does each competitor communicate value? - -- **Level 1 - Category**: What category do they claim? CRM, project management, collaboration platform, etc. -- **Level 2 - Differentiator**: What makes them different within that category? AI-powered, all-in-one, developer-first, etc. -- **Level 3 - Value Proposition**: What outcome do they promise? Close deals faster, ship products faster, never miss a deadline, etc. -- **Level 4 - Proof Points**: What evidence do they provide? Customer logos, metrics, awards, case studies. - -### Positioning Gaps and Opportunities - -Look for: -- **Unclaimed positions**: Value propositions no competitor owns that matter to buyers. -- **Crowded positions**: Claims every competitor makes that have lost meaning. -- **Emerging positions**: New value propositions driven by market changes such as AI, remote work, or compliance. -- **Vulnerable positions**: Claims competitors make that they cannot fully deliver on. - -## Win/Loss Analysis Methodology - -### Conducting Win/Loss Analysis - -Win/loss analysis reveals why you actually win and lose deals. It is the most actionable competitive intelligence. - -Data sources: -- CRM notes from sales team: available immediately, but biased -- Customer interviews shortly after decision: most valuable, least biased -- Churned customer surveys or exit interviews -- Prospect surveys for lost deals - -### Win/Loss Interview Questions - -For wins: -- What problem were you trying to solve? -- What alternatives did you evaluate? -- Why did you choose us over alternatives? -- What almost made you choose someone else? -- What would we need to lose for you to reconsider? - -For losses: -- What problem were you trying to solve? -- What did you end up choosing? Why? -- Where did our product fall short? -- What could we have done differently? -- Would you reconsider us in the future? Under what conditions? - -### Analyzing Win/Loss Data - -- Track win/loss reasons over time. Are patterns changing? -- Segment by deal type: enterprise versus SMB, new versus expansion, industry vertical. -- Identify the top 3-5 reasons for wins and losses. -- Distinguish product reasons such as features and quality from non-product reasons such as pricing, brand, relationship, and timing. -- Calculate competitive win rates by competitor: what percentage of deals involving each competitor do you win? - -### Common Win/Loss Patterns - -- **Feature gap**: Competitor has a specific capability you lack that is a dealbreaker. -- **Integration advantage**: Competitor integrates with tools the buyer already uses. -- **Pricing structure**: Not always cheaper; sometimes a different pricing model such as per-seat versus usage-based fits better. -- **Incumbent advantage**: Buyer sticks with what they have because switching cost is too high. -- **Sales execution**: Better demo, faster response, more relevant case studies. -- **Brand/trust**: Buyer chooses the safer or more well-known option. - -## Market Trend Identification - -### Sources for Trend Identification - -- Industry analyst reports: Gartner, Forrester, IDC for market sizing and trends. -- Venture capital: What are VCs funding? Investment themes signal where smart money sees opportunity. -- Conference themes: What are industry events focusing on? What topics draw the biggest audiences? -- Technology shifts: New platforms, APIs, or capabilities that enable new product categories. -- Regulatory changes: New regulations that create requirements or opportunities. -- Customer behavior changes: How are user expectations evolving? -- Talent movement: Where are top people going? What skills are in demand? - -### Trend Analysis Framework - -For each trend identified: - -1. **What is changing?** Describe the trend clearly and specifically. -2. **Why now?** What is driving this change: technology, regulation, behavior, economics? -3. **Who is affected?** Which customer segments or market categories? -4. **What is the timeline?** Is this happening now, in 1-2 years, or 3-5 years? -5. **What is the implication for us?** How should this influence product strategy? -6. **What are competitors doing?** How are competitors responding to this trend? - -### Separating Signal From Noise - -- **Signals**: Trends backed by behavioral data, growing investment, regulatory action, or customer demand. -- **Noise**: Trends backed only by media hype, conference buzz, or competitor announcements without customer traction. -- Test trends against your own customer data: are your customers asking for this or experiencing this change? -- Be wary of trend-of-the-year hype cycles. Many trends that dominate industry conversation do not materially affect customers for years. - -### Strategic Response Options - -For each significant trend: -- **Lead**: Invest early and try to define the category or approach. High risk, high reward. -- **Fast follow**: Wait for early signals of customer demand, then move quickly. Lower risk but harder to differentiate. -- **Monitor**: Track the trend but do not invest yet. Set triggers for when to act. -- **Ignore**: Explicitly decide this trend is not relevant to your strategy. Document why. - -The right response depends on competitive position, customer base, resources, and trend speed. - -## Output Format - -Use clear headers and tables for feature comparisons. Keep strategic implications concise and actionable. - -Return this structure: - -```text -# Competitive Brief: [Competitor(s) or Feature Area] - -## Scope -- Competitor(s) or feature area: -- Focus: -- Decision context: -- Sources used: -- Date: - -## Executive Summary -- Bottom line: -- Biggest competitive strength: -- Biggest competitive weakness: -- Highest-priority strategic implication: - -## Competitive Landscape -[Direct, indirect, adjacent, and substitute competitors.] - -## Competitor Overview -[Overview per competitor.] - -## Feature Comparison -[Capability matrix plus notes on evidence and caveats.] - -## Positioning Analysis -[Positioning statement, message architecture, gaps, and opportunities.] - -## Strengths and Weaknesses -[Evidence-based strengths and weaknesses per competitor.] - -## Opportunities -[Strategic opportunities and customer gaps.] - -## Threats -[Competitive threats and nightmare scenarios.] - -## Win/Loss Signals -[Available win/loss patterns, questions to investigate, and deal implications.] - -## Market Trends -[Relevant trends, signal/noise assessment, and strategic response.] - -## Strategic Implications -[Build, accelerate, deprioritize, differentiate, parity, positioning, and monitoring recommendations.] - -## Follow-Ups -[Recommended deeper dives, executive summary, battle card, how-to-win guide, or monitoring plan.] -``` - -## Tips - -- Be honest about competitor strengths. Dismissing competitors makes the analysis useless. -- Focus on what matters to customers, not what matters to product teams. -- Pricing is hard to compare fairly. Note caveats such as different packaging, usage-based versus seat-based pricing, and enterprise custom pricing. -- Job postings are underrated competitive intelligence. A competitor hiring ML engineers signals a strategic direction. -- Customer reviews are valuable because they reveal what real users love and hate, less filtered by marketing. -- The most valuable part of competitive analysis is the "so what": strategic implications. Do not skip it. -- Competitive analysis has a shelf life. Note the date and flag areas that change quickly. diff --git a/.agents/skills/productize-competitive-brief/references/pm-skills-main-merge.md b/.agents/skills/productize-competitive-brief/references/pm-skills-main-merge.md deleted file mode 100644 index 39261a4b..00000000 --- a/.agents/skills/productize-competitive-brief/references/pm-skills-main-merge.md +++ /dev/null @@ -1,191 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM sources when the competitive artifact must become sales-ready battlecard material, not only product strategy research. - -## Routing Signals - -- competitive battlecard -- sales battlecard -- objection handling -- win loss - -## pm-go-to-market/skills/competitive-battlecard/SKILL.md - -## Competitive Battlecard - -Create a concise, sales-ready battlecard for use against a specific competitor. - -### Context - -You are creating a competitive battlecard for **$ARGUMENTS**. - -Use web search to research the competitor's current product, pricing, positioning, and recent changes. If the user provides files (feature lists, win/loss data, sales call notes), read them first. - -### Instructions - -1. **Research the competitor** (use web search): - - Current product offerings and features - - Pricing tiers and model - - Target market and positioning - - Recent product launches or changes - - Known strengths and weaknesses - - Customer reviews and sentiment (G2, Capterra, Reddit) - -2. **Create the battlecard** with these sections: - - ### Company Overview - - Founded, HQ, funding/revenue (if public) - - Target market and ICP - - Positioning in one sentence - - ### Quick Comparison - - | Capability | Us | Them | Winner | - |---|---|---|---| - | [Feature area 1] | [Our approach] | [Their approach] | [Us/Them/Tie] | - | [Feature area 2] | ... | ... | ... | - | Pricing | ... | ... | ... | - | Support | ... | ... | ... | - - ### Where We Win - - [Advantage 1]: [Proof point or customer quote] - - [Advantage 2]: [Specific capability they lack] - - [Advantage 3]: [Better approach with reasoning] - - ### Where They Win - - [Their strength 1]: [Our counter-positioning] - - [Their strength 2]: [How we mitigate this gap] - - ### Common Objections & Responses - - | Prospect Says | Respond With | - |---|---| - | "Competitor X has [feature]" | "[Our alternative approach and why it's better for them]" | - | "They're cheaper" | "[Value framing: total cost of ownership, ROI, hidden costs]" | - | "They're more established" | "[Our advantages: speed, innovation, focus, support]" | - - ### Landmines to Plant - Questions to ask the prospect that highlight competitor weaknesses: - - "How important is [area where we excel] to your team?" - - "Have you evaluated [specific capability they lack]?" - - ### Win/Loss Patterns - - We tend to win when: [pattern] - - We tend to lose when: [pattern] - - Key differentiator in competitive deals: [what tips the scale] - -3. **Keep it scannable**: Sales reps need to reference this during calls. Use tables, bold text, and short bullets. - -Save as markdown. Format for easy printing or sharing in Notion/Confluence. - ---- - -### Further Reading - -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## pm-market-research/skills/competitor-analysis/SKILL.md - -## Purpose -Conduct a comprehensive competitive analysis to understand the landscape, identify 5 direct competitors, and uncover differentiation opportunities. This skill maps competitive positioning, synthesizes competitor strengths and weaknesses, and highlights opportunities for strategic differentiation. - -## Instructions - -You are a strategic product analyst and competitive intelligence expert specializing in competitive positioning and market landscape mapping. - -### Input -Your task is to analyze the competitive landscape for **$ARGUMENTS** in the **[market/industry segment]** (if specified). - -Conduct web research to identify direct competitors. If the user provides market research, competitor data, pricing sheets, feature comparisons, or customer feedback about competitors, read and analyze them directly. Synthesize data into a comprehensive competitive view. - -### Analysis Steps (Think Step by Step) - -1. **Market Scoping**: Define the market, industry, and addressable customer base for $ARGUMENTS -2. **Competitor Identification**: Use web search to identify 5 primary direct competitors -3. **Competitive Intelligence**: Research each competitor's positioning, features, pricing, go-to-market strategy -4. **Strengths & Weaknesses**: Assess competitor capabilities, limitations, and market positioning -5. **Differentiation Mapping**: Identify gaps, overlaps, and opportunities for $ARGUMENTS to differentiate -6. **Strategic Synthesis**: Develop insights about competitive dynamics and future threats - -### Output Structure - -**Market Overview & Definition** -- Market size and growth trends -- Primary customer segments and use cases -- Key success factors in this market -- Market dynamics and competitive intensity - -**Competitive Set Summary** -- 5 primary direct competitors identified -- Market positions: leaders, challengers, niche players -- Estimated market share or positioning -- Notable adjacent or indirect competitors - -For each of the 5 competitors: - -**Competitor Profile** -- Company name, founding date, funding/status -- Primary market focus and customer segments served -- Estimated market share or customer base size -- Market positioning and go-to-market strategy - -**Core Product Strengths** -- Key features and capabilities -- Unique competitive advantages -- Customer value proposition -- Technology differentiation or moats -- Customer satisfaction and retention signals - -**Product Weaknesses & Gaps** -- Missing features or use cases -- Known limitations or pain points for customers -- Technical or operational weaknesses -- Market positioning gaps -- Customer dissatisfaction areas - -**Business Model & Pricing** -- Pricing structure (per-seat, per-usage, flat-fee, freemium, etc.) -- Price point(s) in market -- Go-to-market channels and sales motion -- Revenue model and growth stage - -**Competitive Threats & Advantages** -- How this competitor threatens $ARGUMENTS -- Existing customer base and switching costs -- Strategic partnerships or ecosystems -- Recent product updates or strategic moves - -**Differentiation Opportunities for $ARGUMENTS** - -- Unmet customer needs across competitive set -- Feature/pricing/UX opportunities to stand out -- Target segments underserved by competitors -- Jobs-to-be-done not effectively solved by competitors -- Channel or go-to-market approaches not yet deployed -- Potential partnerships or integrations competitors lack - -**Competitive Positioning Recommendation** -- Recommended competitive positioning for $ARGUMENTS -- Key differentiators to emphasize -- Segments or use cases to target or avoid -- Competitive threats to monitor -- 12-18 month competitive risks and opportunities - -## Best Practices - -- Research current competitor websites, pricing pages, and customer reviews -- Use web search to identify product launches, funding, executive moves -- Distinguish between direct competitors and adjacent alternatives -- Validate competitive insights across multiple sources -- Identify both obvious and subtle differentiation opportunities -- Consider customer pain points not yet addressed in market -- Look for emerging competitors or new market entrants -- Flag competitors gaining traction or gaining market share -- Consider long-term competitive dynamics and market shifts - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) diff --git a/.agents/skills/productize-draft-nda/SKILL.md b/.agents/skills/productize-draft-nda/SKILL.md deleted file mode 100644 index ff863aab..00000000 --- a/.agents/skills/productize-draft-nda/SKILL.md +++ /dev/null @@ -1,245 +0,0 @@ ---- -name: productize-draft-nda -description: >- - Draft NDA. Use when drafting a confidentiality or NDA document for partnership, customer, - vendor, hiring, or product collaboration discussions. ---- - - - -# Draft NDA - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `draft-nda` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: NDA draft for legal review with assumptions, clauses, and review flags - -Use when drafting a confidentiality or NDA document for partnership, customer, vendor, hiring, or product collaboration discussions. - -## Productize Contract - -- **Primary lifecycle**: Align -- **Supporting lifecycle**: none -- **Primary artifact**: NDA draft for legal review with assumptions, clauses, and review flags -- **Source method**: pm-skills-main/pm-toolkit/skills/draft-nda/SKILL.md - -## Legal Review Guardrail - -This skill creates a product/legal working draft for review. Do not present the output as legal advice or final compliance approval. Flag jurisdiction, data, party, and policy assumptions for qualified review. - -## Method - -You are an experienced legal document specialist with expertise in confidentiality agreements. Your role is to help draft detailed, clear, and professional Non-Disclosure Agreements between parties. - -## Purpose -Draft a comprehensive Non-Disclosure Agreement (NDA) between two parties. The NDA covers information types, jurisdiction, and clearly marks clauses that require legal review. Provide plain-language explanations to make the document accessible. - -## Important Disclaimer -**This is for informational purposes only and does not constitute legal advice. Always have a licensed attorney review the final document before execution. NDAs are legally binding contracts; professional legal review is essential.** - -## Input Arguments -- `$COMPANY_ONE_NAME`: Name of the first party/company -- `$COMPANY_ONE_ADDRESS`: Address of the first party/company -- `$COMPANY_ONE_REPS`: Names and titles of representatives (e.g., "John Smith, CEO; Jane Doe, General Counsel") -- `$COMPANY_TWO_NAME`: Name of the second party/company -- `$COMPANY_TWO_ADDRESS`: Address of the second party/company -- `$COMPANY_TWO_REPS`: Names and titles of representatives -- `$INFORMATION_TYPES`: Types of information to be shared (e.g., "business plans, customer lists, technical specifications, pricing data, source code") -- `$JURISDICTION`: Governing jurisdiction (e.g., "State of California, United States" or "England and Wales") - -## Process - -### Step 1: Clarify Requirements -Before drafting, note down: -- Are both parties companies or is one an individual? -- What specific types of information will be shared? -- Is this one-way (only one party shares) or mutual (both parties share)? -- What is the geographic jurisdiction? -- What is the intended duration of the NDA? - -### Step 2: Structure the NDA -Organize the NDA in standard sections: - -1. **Preamble** (Parties, definitions, effective date) -2. **Definitions** (What is "Confidential Information"?) -3. **Obligation to Maintain Confidentiality** (Core obligation) -4. **Permitted Disclosures** (Exceptions to confidentiality) -5. **Term and Duration** (How long does the NDA last?) -6. **Return or Destruction of Information** (What happens after?) -7. **Remedies** (Consequences for breach) -8. **General Provisions** (Governing law, jurisdiction, severability) - -### Step 3: Use Plain Language -Write each section in clear, accessible language. Avoid legal jargon where possible. Define terms the first time they're used. - -### Step 4: Highlight Clauses Needing Legal Review -Mark sections with [ LEGAL REVIEW REQUIRED] where customization or specific legal expertise is needed. Include explanations of what should be reviewed. - -### Step 5: Provide Context -Include brief notes explaining: -- Why each section is important -- What decisions need to be made by the parties -- Common pitfalls or considerations - -## NDA Template Structure - -Present the draft NDA in this order: - -**[COVER NOTE]** -A brief note explaining the NDA's purpose, the parties involved, and key provisions. - -**[FULL NDA DOCUMENT]** -The complete agreement ready for customization. - -**[NOTES ON KEY CLAUSES]** -Explanations of important sections and what may need legal customization. - ---- - -## Key Sections to Include - -### Preamble -- Introduce both parties clearly with full legal names and addresses -- State the purpose: exploring a potential business relationship, partnership, merger, etc. -- Define the "Effective Date" - -### Definitions -- **Confidential Information**: Specify what is considered confidential (business plans, financial data, technical specs, customer lists, etc.). Include scope. -- **Excluded Information**: Clarify what is NOT confidential (publicly available information, information independently developed, information received from third parties without confidentiality obligations) - -### Obligations -- Describe the receiving party's duty to keep information confidential -- Specify approved uses of the information -- Outline permitted disclosures (to employees, advisors, on a need-to-know basis) -- [ LEGAL REVIEW REQUIRED] Standard of care (e.g., "same care as own confidential information, but no less than reasonable care") - -### Permitted Disclosures -- Specify who can be told (employees, advisors, consultants on a need-to-know basis) -- Include a requirement that recipients also agree to confidentiality -- Add exception for legally required disclosures (with notice requirement, if possible) - -### Term and Duration -- Define the period during which information is being shared -- Define how long confidentiality obligations survive after the relationship ends -- [ LEGAL REVIEW REQUIRED] Consider different durations for different information types (trade secrets may require longer protection) - -### Return or Destruction -- Specify that the receiving party must return or securely destroy confidential information upon request or upon termination -- Option to certify in writing that destruction is complete -- Consider: does the receiving party keep one copy for legal compliance? - -### Remedies -- [ LEGAL REVIEW REQUIRED] State that breach may cause irreparable harm and that injunctive relief is available -- Clarify that remedies are in addition to other legal remedies available - -### General Provisions -- **Governing Law and Jurisdiction**: Specify which state or country's laws govern (e.g., California or England) -- [ LEGAL REVIEW REQUIRED] Dispute resolution process (litigation, arbitration, mediation) -- **Severability**: If one provision is invalid, others remain in force -- **Entire Agreement**: This NDA supersedes prior discussions -- **Amendments**: Specify that NDA can only be modified in writing, signed by both parties -- **Counterparts**: Parties can sign separate copies - ---- - -## Content Guidelines - -- **Plain Language**: Write for a primary-school-educated reader. Avoid Latin phrases, unnecessary legal terms. -- **Clarity over Precision**: Choose clear language first. Legal precision can be refined by attorneys. -- **Examples**: Where helpful, include examples of what is/isn't confidential information. -- **Specific Information Types**: Use the $INFORMATION_TYPES provided to make the agreement specific, not generic. -- **Mutual or One-Way**: If $INFORMATION_TYPES suggests only one party is sharing, note this as a one-way NDA. If both, use mutual language. - ---- - -## Output Format - -Present the NDA in three parts: - -### Part 1: Summary -Bullet-point overview of: -- Parties involved -- Information types covered -- Key duration and terms -- Jurisdiction - -### Part 2: Full NDA Document -A complete, ready-to-customize NDA document. - -### Part 3: Customization Notes -Guidance on: -- Sections marked for legal review -- Decisions parties need to make -- Common modifications based on situation -- Next steps (legal review, signing process) - ---- - -## Important Reminders - -- This is a starting point, not final legal advice -- Jurisdictions vary widely; have a lawyer in the relevant jurisdiction review -- Some industries (tech, pharma, finance) have specific NDA conventions -- Consider mutual vs. one-way requirements -- Think about duration: How long should the information be protected? -- Always have an attorney review before any party signs - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-effective-customer-interview-guides-for-any-topic/SKILL.md b/.agents/skills/productize-effective-customer-interview-guides-for-any-topic/SKILL.md deleted file mode 100644 index fba99410..00000000 --- a/.agents/skills/productize-effective-customer-interview-guides-for-any-topic/SKILL.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -name: productize-effective-customer-interview-guides-for-any-topic -description: >- - Effective customer interview guides for any topic. Use when the user needs a product - workflow for user research related to effective customer interview guides for any topic. - Trigger terms: user-research, interviews, discussion-guide. ---- - - - -# Effective customer interview guides for any topic - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `effective-customer-interview-guides-for-any-topic` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Effective customer interview guides for any topic research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Effective customer interview guides for any topic**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: Effective customer interview guides for any topic. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Create a comprehensive customer interview discussion guide for `{{TOPIC}}` to support feature-development insights. -- Internally analyze topic components, interview priorities, and interview flow before writing the final guide. -- Build sections in this order: -- Introduction and warm-up. -- Current situation and workflow. -- Challenges and pain points. -- Desired outcomes and goals. -- Exploration of potential solutions. -- Wrap-up and next steps. -- Use best practices from Mom Test and Continuous Discovery Habits: -- Open-ended, non-leading, behavior-based questions. -- Focus on past experiences over hypotheticals. -- Prioritize highest-value questions first in each section. -- Use friendly professional tone, numbered questions, and optional interviewer prompts in `[brackets]`. -- Output only the final ``; do not include analysis/thinking notes. - -FORMAT -Return exactly this structure: - - -[Brief introduction for the interviewer, explaining the purpose of the interview and key points to remember] - -1. Introduction and Warm-up - 1.1. [Question] - 1.2. [Question] - [Additional questions as needed] - -2. Current Situation and Workflow - 2.1. [Question] - 2.2. [Question] - [Additional questions as needed] - -3. Challenges and Pain Points - 3.1. [Question] - 3.2. [Question] - [Additional questions as needed] - -4. Desired Outcomes and Goals - 4.1. [Question] - 4.2. [Question] - [Additional questions as needed] - -5. Exploration of Potential Solutions - 5.1. [Question] - 5.2. [Question] - [Additional questions as needed] - -6. Wrap-up and Next Steps - 6.1. [Question] - 6.2. [Question] - [Additional questions as needed] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Required sections are missing or question numbering/order is inconsistent. -- Questions are leading, hypothetical-first, or not behavior-based. -- Questions are not prioritized by importance within each section. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `interview script`, `mom test`, `warm-up`, `jtbd probing`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-effective-customer-interview-guides-for-any-topic/references/pm-skills-main-merge.md b/.agents/skills/productize-effective-customer-interview-guides-for-any-topic/references/pm-skills-main-merge.md deleted file mode 100644 index a08bd2e5..00000000 --- a/.agents/skills/productize-effective-customer-interview-guides-for-any-topic/references/pm-skills-main-merge.md +++ /dev/null @@ -1,113 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to strengthen interview scripts with warm-up, core exploration, wrap-up, Mom Test behavior, and non-leading JTBD probes. - -## Routing Signals - -- interview script -- mom test -- warm-up -- jtbd probing - -## pm-product-discovery/skills/interview-script/SKILL.md - -## Customer Interview Script - -Create a structured interview script that surfaces real insights, not just opinions. Follows "The Mom Test" principles -- ask about their life, not your idea. - -### Domain Context - -Customer interviews are one source in **Stage 1 (Explore)** of continuous discovery. Other sources: stakeholder interviews, usage analytics, data analytics, surveys, market trends, SEO/SEM analysis. The PM needs direct access to users, stakeholders, engineers, and designers -- "without proxies." The **Product Trio** (PM + Designer + Engineer -- Teresa Torres) should work together on discovery, not just the PM alone. - -### Context - -You are preparing a customer interview script for research on **$ARGUMENTS**. - -If the user provides files (personas, hypothesis lists, product briefs, or previous interview notes), read them first. - -### Instructions - -1. **Clarify research objectives**: - - What specific questions does the team need answered? - - What decisions will this research inform? - - What assumptions need validation? - -2. **Create the interview script** with these sections: - - ### Opening (2-3 min) - - Introduce yourself and the purpose (learning, not selling) - - Set expectations: "There are no right or wrong answers. We're here to learn from your experience." - - Ask permission to record (if applicable) - - Confirm time available - - ### Warm-Up: Context & Background (5 min) - - "Tell me about your role and what a typical day/week looks like." - - "How long have you been doing [activity related to the product area]?" - - Goal: Build rapport and understand their context - - ### Core Exploration: Jobs to Be Done (15-20 min) - - **Current situation and behavior** (past tense, specific instances): - - "Walk me through the last time you [did the thing we're exploring]. What happened?" - - "What tools or methods did you use?" - - "How long did it take? Who else was involved?" - - **Pain points and frustrations** (observe, don't lead): - - "What was the hardest part about that?" - - "If you could wave a magic wand, what would change?" - - "What have you tried to solve this? What happened?" - - **Desired outcomes** (their words, not yours): - - "What does 'good' look like for you in this area?" - - "How would you know if this was working well?" - - **Willingness to pay / priority** (skin in the game): - - "How much time/money do you currently spend on this?" - - "Have you looked for a better solution? What did you find?" - - "What would you give up to have this solved?" - - ### Probing Techniques - Use these when you hit an interesting thread: - - **"Tell me more about that"** -- opens up any topic - - **"Why?"** (asked gently, 2-3 times) -- gets to root causes - - **"Can you give me a specific example?"** -- moves from opinions to facts - - **"What happened next?"** -- follows the story - - **"How did that make you feel?"** -- captures emotional intensity - - ### The Mom Test Rules - - Ask about **their life**, not your idea - - Ask about **the past**, not the future ("Would you use X?" is useless) - - **Talk less, listen more** -- aim for 80/20 split - - **Never pitch** during the interview - - Look for **strong emotions** -- they signal real pain or delight - - **Compliments are noise** -- "That sounds cool!" tells you nothing - - ### Wrap-Up (3-5 min) - - "Is there anything I didn't ask that you think is important?" - - "Who else should I talk to about this?" - - Thank them for their time - - Share next steps (if any) - -3. **Customize the script**: Adapt questions to the specific product area, persona, and research objectives. Add or remove sections based on the interview length available. - -4. **Include a note-taking template**: - ``` - Participant: [Name / ID] - Date: [Date] - Key Jobs: [What they're trying to accomplish] - Current Solution: [What they use today] - Biggest Pain: [Their #1 frustration] - Desired Outcome: [What success looks like] - Willingness to Pay: [How much they invest / would invest] - Surprise Finding: [Something unexpected] - Follow-up: [Next steps] - ``` - -Save as markdown. Include both the script and the note-taking template. - ---- - -### Further Reading - -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) diff --git a/.agents/skills/productize-group-decision-making-quality-review/SKILL.md b/.agents/skills/productize-group-decision-making-quality-review/SKILL.md deleted file mode 100644 index cb5bacdc..00000000 --- a/.agents/skills/productize-group-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: productize-group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, or - operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group - decides. ---- - - - -# Group Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `group-decision-making-quality-review` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/.agents/skills/productize-growth-loops/SKILL.md b/.agents/skills/productize-growth-loops/SKILL.md deleted file mode 100644 index 4f439fbc..00000000 --- a/.agents/skills/productize-growth-loops/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: productize-growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- - - - -# Growth Loops - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-loops` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-gtm-motions/SKILL.md b/.agents/skills/productize-gtm-motions/SKILL.md deleted file mode 100644 index a9650ffb..00000000 --- a/.agents/skills/productize-gtm-motions/SKILL.md +++ /dev/null @@ -1,236 +0,0 @@ ---- -name: productize-gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, - partner, ABM, or hybrid go-to-market motions. ---- - - - -# GTM Motions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-motions` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-gtm-strategy/SKILL.md b/.agents/skills/productize-gtm-strategy/SKILL.md deleted file mode 100644 index 22360c0b..00000000 --- a/.agents/skills/productize-gtm-strategy/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: productize-gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- - - - -# GTM Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md b/.agents/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md deleted file mode 100644 index 5d62c3c7..00000000 --- a/.agents/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- - - - -# Ideal Customer Profile (ICP) representative for X product - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideal-customer-profile-icp-representative-for-x-product` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md b/.agents/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md deleted file mode 100644 index 3be9171c..00000000 --- a/.agents/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md +++ /dev/null @@ -1,171 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make ICP outputs sharper on demographics, behaviors, JTBD, PMF evidence, and best-customer patterns. - -## Routing Signals - -- ideal customer profile -- icp -- pmf survey -- best customers - -## pm-go-to-market/skills/ideal-customer-profile/SKILL.md - -## Overview -Identify your Ideal Customer Profile (ICP) from research and survey data. This skill synthesizes customer research to define the customer most likely to find value, retain, and expand with your product. - -## When to Use -- Defining ICP from product-market fit survey data -- Targeting high-value customer segments -- Analyzing customer success and expansion patterns -- Prioritizing sales and marketing efforts -- Evaluating new customer opportunities for fit -- Refining target market definition - -## ICP Framework Components - -### Demographics -Who are they from a firmographic and personal perspective? -- Company size (employees, revenue) -- Industry or vertical -- Geographic location -- Job title and department -- Years of experience in role -- Education and background -- Organizational structure and reporting - -### Behaviors -How do they work and make decisions? -- How they discover and evaluate solutions -- Buying process and decision-making timeline -- Technical literacy and product adoption speed -- Collaboration style (solo decision vs committee) -- Change management and adoption style -- Tool switching frequency -- Community involvement and peer influence - -### Jobs to Be Done (JTBD) -What are they trying to accomplish? -- Primary job/goal they're trying to achieve -- Secondary jobs that support the primary job -- Emotional jobs (how they want to feel) -- Social jobs (status and perception) -- Jobs they avoid or want to eliminate -- Frequency and importance of each job -- Success metrics for completing job - -### Needs and Pain Points -What problems does your product solve? -- Specific pain points they experience -- Current workarounds and limitations -- Impact on productivity or outcomes -- Cost or time burden of the problem -- Emotional frustration levels -- Barriers to solving the problem -- Available budget to solve -- Competing priorities - -## How It Works - -### Step 1: Gather Customer Data -Collect research about actual and potential customers: -- Product-market fit survey responses -- Customer interview transcripts -- Trial or freemium user behavior data -- Customer feedback and support tickets -- Churn analysis and customer lifecycle data -- Win/loss analysis from sales -- Competitor customer analysis - -### Step 2: Segment by Value -Identify customer cohorts and their value: -- Highest LTV (lifetime value) customers -- Fastest time-to-value customers -- Lowest churn rate customers -- Highest expansion/upsell customers -- Most enthusiastic/engaged customers -- Best reference/case study potential -- Most aligned with product vision - -### Step 3: Profile Demographics -Extract firmographic patterns: -- Common company sizes (employee count, revenue) -- Industry verticals and sub-verticals -- Geographic concentrations -- Typical department and reporting structure -- Budget holders and budget available -- Company stage (startup, growth, enterprise) -- Company culture indicators - -### Step 4: Identify Behaviors -Map decision-making and adoption patterns: -- How they discovered your product (channel) -- Evaluation process and timeline -- Key stakeholders in decision -- Obstacles during sales process -- Product adoption speed and breadth -- Team involvement in onboarding -- Frequency of feature usage -- Support and service needs - -### Step 5: Define JTBD -Articulate what they're trying to accomplish: -- Primary job/goal (functional job) -- Emotional dimensions (how they want to feel) -- Social dimensions (team and stakeholder impact) -- Success metrics (how they measure success) -- Context and constraints (when, where, with whom) -- Competing jobs and priorities -- Importance ranking of various jobs - -### Step 6: Document Pain Points and Needs -Synthesize specific problem areas: -- Before state (current situation and frustrations) -- Desired after state (ideal future state) -- Gap size and impact quantification -- Emotional dimensions of the problem -- Resource constraints preventing solutions -- Skepticism or hesitations -- Success criteria for solution - -## Input Format -Use $ARGUMENTS to pass: -- Research data (surveys, interviews, transcripts) -- Customer success/metrics data -- Product usage analytics -- Sales activity and win/loss data -- Existing customer database -- Competitive intelligence - -## Output -A comprehensive ICP definition including: -- Firmographic profile (company size, industry, location) -- Behavioral profile (buying patterns, adoption style) -- Complete JTBD mapping (functional, emotional, social jobs) -- Top 5-7 pain points and specific needs -- Quantified impact metrics (cost of problem, value of solution) -- Decision-making process and key stakeholders -- Typical customer journey and timeline -- Go-to-market implications and messaging -- Disqualification criteria (who is NOT a good fit) -- High-value segment within ICP (ideal-of-the-ideal) - -## Framework -Based on Jobs to Be Done theory by Clayton Christensen and customer profiling methodology. Combines behavioral data with motivational insights to define actionable customer profiles. - -## Tips -- Use quantitative and qualitative data together -- Interview 10+ high-value customers for pattern identification -- Look for non-obvious demographic patterns (outliers can be high-value) -- Define both ideal ICP and acceptable secondary segments -- Revisit ICP quarterly as you gather more customer data -- Use ICP to evaluate all new sales opportunities -- Share ICP across entire organization (marketing, sales, product) -- Remember: ICP should drive focus, not exclude all others - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/.agents/skills/productize-lean-canvas/SKILL.md b/.agents/skills/productize-lean-canvas/SKILL.md deleted file mode 100644 index b3a18d33..00000000 --- a/.agents/skills/productize-lean-canvas/SKILL.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -name: productize-lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- - - - -# Lean Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `lean-canvas` -- **Lifecycle**: Think -- **Category**: Business Model -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-market-sizing/SKILL.md b/.agents/skills/productize-market-sizing/SKILL.md deleted file mode 100644 index 6467fec0..00000000 --- a/.agents/skills/productize-market-sizing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, - market-entry upside, or investor-ready opportunity size. ---- - - - -# Market Sizing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-sizing` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md b/.agents/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md deleted file mode 100644 index bbf05acf..00000000 --- a/.agents/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: productize-meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- - - - -# Meeting Outcome Planning and Stakeholder Alignment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-outcome-planning-and-stakeholder-alignment` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.agents/skills/productize-monetization-strategy/SKILL.md b/.agents/skills/productize-monetization-strategy/SKILL.md deleted file mode 100644 index e071d8c9..00000000 --- a/.agents/skills/productize-monetization-strategy/SKILL.md +++ /dev/null @@ -1,231 +0,0 @@ ---- -name: productize-monetization-strategy -description: >- - Monetization Strategy. Use when deciding how a product should make money, comparing revenue - models, or exploring monetization options before detailed pricing. ---- - - - -# Monetization Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `monetization-strategy` -- **Lifecycle**: Strategize -- **Category**: Business Model -- **Primary artifact**: Monetization options brief with audience fit, risks, and validation experiments - -Use when deciding how a product should make money, comparing revenue models, or exploring monetization options before detailed pricing. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: Monetization options brief with audience fit, risks, and validation experiments -- **Source method**: pm-skills-main/pm-product-strategy/skills/monetization-strategy/SKILL.md - -## Method - -## Metadata -- **Name**: monetization-strategy -- **Description**: Brainstorm 3-5 monetization strategies with audience fit, risks, and validation experiments. Use when exploring revenue models, pricing strategies, or business model options. -- **Triggers**: monetization strategy, revenue model, pricing strategy, how to monetize, make money - -## Instructions - -You are an experienced business model strategist brainstorming monetization strategies for $ARGUMENTS. - -Your task is to develop 3-5 distinct monetization approaches that could work for the product or feature, evaluate fit with the target market, and outline low-effort validation experiments. - -## Input Requirements -- Product or feature description -- Target market segment(s) and customer profile -- Current willingness to pay or budget constraints -- Competitive monetization approaches -- Company priorities (revenue growth, user growth, profitability) - -## Monetization Framework - -For each strategy, include: - -### 1. Strategy Name & Description -- What is the monetization model? -- How does it work for this product? -- Who pays and what do they get? - -### 2. How It Works -- Revenue model and pricing mechanics -- Value exchange between company and customer -- Payment frequency and transaction size -- Lifecycle and retention mechanisms - -### 3. Audience Fit -- Why does this resonate with your target customer? -- How does it align with customer needs and preferences? -- What problems does it solve for the customer? -- Addressable market size and revenue potential - -### 4. Unit Economics -- Estimated customer acquisition cost (CAC) -- Estimated customer lifetime value (LTV) -- Break-even timeline -- Target gross margin - -### 5. Risks & Challenges -- Market adoption risk -- Pricing or feature sensitivity -- Competitive vulnerability -- Customer churn or resistance -- Implementation complexity - -### 6. Competitive Position -- How do competitors monetize? -- What makes your approach differentiated? -- Barriers to customer switching -- Defense against competitive pricing - -### 7. Validation Experiment -- Low-cost test to validate customer willingness to pay -- Method: survey, landing page, pilot, freemium, waitlist -- Success metric and decision criteria -- Timeline and resources required - -## Example Monetization Strategies - -### 1. Freemium (Free Base + Paid Premium) -- **How**: Free core features, premium advanced features behind paywall -- **Fit**: Best for high-volume, low-touch products (design tools, productivity, communication) -- **Risks**: Low conversion rates (typically 1-5%), features must be clear to justify upgrade -- **Experiment**: Launch freemium version, track conversion rate, gather upgrade feedback - -### 2. Subscription (Recurring Monthly/Annual) -- **How**: Recurring charge for ongoing access and updates -- **Fit**: Best for products with continuous value (software, platforms, services) -- **Risks**: Customer churn, cannibalization from annual vs. monthly -- **Experiment**: Offer subscription to beta customers, measure churn rate and NPS - -### 3. Usage-Based (Pay Per Use) -- **How**: Customers pay based on usage volume (API calls, storage, transactions) -- **Fit**: Best for B2B platforms, APIs, services with variable customer needs -- **Risks**: Unpredictable revenue, customer cost anxiety, usage optimization by customers -- **Experiment**: Implement usage tracking, pilot with 5-10 beta customers, model revenue - -### 4. Enterprise/Seat-Based (Per User/Seat) -- **How**: Price per user, department, or seat using the product -- **Fit**: Best for B2B SaaS with team/organization adoption -- **Risks**: Sales complexity, contract length, implementation overhead -- **Experiment**: Conduct 5-10 customer interviews, validate pricing per seat, define support model - -### 5. One-Time Purchase (Buy Once) -- **How**: Single upfront purchase for permanent or one-time license -- **Fit**: Best for niche products, tools, or templates (not ongoing services) -- **Risks**: Revenue concentration in launch period, no recurring revenue, updates/support questions -- **Experiment**: Launch limited offering, track conversion and customer satisfaction - -### 6. Marketplace/Transaction Fee -- **How**: Take a percentage or fixed fee from transactions between buyers and sellers -- **Fit**: Best for platforms connecting supply and demand -- **Risks**: Market liquidity chicken-and-egg problem, trust and safety, competitive pressure -- **Experiment**: MVP with limited sellers, offer free period to drive initial supply, model unit economics - -### 7. Advertising/Sponsorship -- **How**: Generate revenue from ads, sponsored content, or brand partnerships -- **Fit**: Best for high-traffic, consumer-facing products -- **Risks**: Brand damage from intrusive ads, user experience degradation, advertiser concentration -- **Experiment**: Test ads with small user segment, measure engagement and revenue impact - -## Output Process -1. Brainstorm 3-5 distinct monetization strategies (avoid repeating similar models) -2. For each strategy: - - Describe how it works specifically for this product - - Assess fit with target customer and willingness to pay - - Outline key risks and challenges - - Estimate unit economics (CAC, LTV, timeline) - - Compare against competitive approaches -3. For each strategy, design a low-effort validation experiment -4. Prioritize by: - - Strategic fit (revenue, growth, profitability goals) - - Ease of implementation - - Market validation potential - - Competitive advantage -5. Recommend 1-2 strategies to test first -6. Create testing roadmap and success criteria - -## Strategic Considerations -- **Revenue Goals**: How much revenue is needed? By when? -- **Growth Goals**: Does monetization need to support user growth? -- **Market Dynamics**: Are customers ready to pay? For what? -- **Competitive Pressure**: How will competitors respond? -- **Unit Economics**: What gross margin is required for viability? - -## Notes -- Best monetization strategies align with customer value and willingness to pay -- Test early and often; don't wait for perfect product to validate pricing -- Most products use hybrid models (e.g., freemium + upgrade, subscription + marketplace fees) -- Pricing can be changed; customer relationships are harder to rebuild -- Monitor competitors but don't race to the bottom on price - ---- - -### Further Reading - -- [Product Pricing Strategies 101](https://www.productcompass.pm/p/product-pricing-strategies-101) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-north-star-metric/SKILL.md b/.agents/skills/productize-north-star-metric/SKILL.md deleted file mode 100644 index 6258a1e9..00000000 --- a/.agents/skills/productize-north-star-metric/SKILL.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -name: productize-north-star-metric -description: >- - North Star Metric. Use when choosing or revising a North Star Metric, defining input - metrics, aligning teams around product value, or deciding what the product should measure. ---- - - - -# North Star Metric - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `north-star-metric` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: North Star metric definition with input metrics, validation criteria, and instrumentation notes - -Use when choosing or revising a North Star Metric, defining input metrics, aligning teams around product value, or deciding what the product should measure. - -## Productize Contract - -- **Primary lifecycle**: Measure -- **Supporting lifecycle**: none -- **Primary artifact**: North Star metric definition with input metrics, validation criteria, and instrumentation notes -- **Source method**: pm-skills-main/pm-marketing-growth/skills/north-star-metric/SKILL.md - -## Method - -Identify a North Star Metric and 3-5 Input Metrics that form a metrics constellation. Classifies the business game being played and validates against criteria for an effective North Star. Use when defining key metrics, setting up a metrics framework, or choosing what to measure. - -## Domain Context - -NSM is **NOT**: multiple metrics, a revenue/LTV metric (must be customer-centric), an OKR (that's a goal-setting technique), or a strategy (but choosing the right NSM is a strategic choice). - -NSM **IS**: a single, customer-centric KPI that reflects the value customers get from the product and serves as a leading indicator of long-term business success. You can use Key Results (OKRs) to express expected change in NSM. - -Free resource: [The North Star Framework 101 (PDF)](https://learn.productcompass.pm/nsm101) - -## When to Use - -- Defining your company's key metric framework -- Setting up a metrics tracking system -- Choosing what to measure and optimize for -- Evaluating potential North Star candidates -- Triggers: North Star metric, north star, key metric, what to measure, metrics framework, OMTM - -## The Three Business Games - -Before identifying your North Star, classify your business into one of these three games: - -- **Attention Game**: How much time do customers spend using your product? (Examples: Facebook, Spotify, YouTube, TikTok) -- **Transaction Game**: How many transactions occur between customers and your platform? (Examples: Amazon, Uber, Airbnb, PayPal) -- **Productivity Game**: How efficiently can someone complete their work or achieve their goals? (Examples: Canva, Dropbox, Loom, Notion) - -## Prompt - -You are a metrics strategist specializing in North Star metrics and growth measurement frameworks. - -Given the following business context: $ARGUMENTS - -**Step 1: Classify the Business Game** -Determine which game this company plays: Attention, Transaction, or Productivity. - -**Step 2: Identify the North Star Metric** -Suggest a single metric that meets all seven criteria for an effective North Star: - -1. **Easy to Understand**: Clear definition that everyone in the organization comprehends -2. **Customer-Centric**: Reflects value delivered to customers, not just revenue or activity -3. **Sustainable Value**: Indicates habits and long-term customer engagement -4. **Vision Alignment**: Represents meaningful progress toward the company's vision and mission -5. **Quantitative**: Measurable with clear, numeric tracking -6. **Actionable**: Teams can directly influence it through product, marketing, and operational changes -7. **Leading Indicator**: Predicts future business success and revenue growth - -**Step 3: Identify Input Metrics** -Define 3-5 Input Metrics (also called leading indicators) that most directly influence and drive the North Star Metric. Each input metric should: -- Be easier to move in the short term -- Directly contribute to the North Star outcome -- Help identify where optimization efforts should focus - -## Tips for Best Results - -- Provide details about your business model and revenue model -- Share your company's vision, mission, or long-term goals -- Include current metrics you're tracking -- Mention key customer segments and use cases -- Describe the primary value you deliver to customers - ---- - -### Further Reading - -- [The North Star Framework 101](https://www.productcompass.pm/p/the-north-star-framework-101) -- [AARRR (Pirate) Metrics: The 5-Stage Framework for Growth](https://www.productcompass.pm/p/aarrr-pirate-metrics) -- [The Google HEART Framework: Your Guide to Measuring User-Centric Success](https://www.productcompass.pm/p/the-google-heart-framework) -- [The Ultimate List of Product Metrics](https://www.productcompass.pm/p/the-ultimate-list-of-product-metrics) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-opportunity-solution-tree-from-input/SKILL.md b/.agents/skills/productize-opportunity-solution-tree-from-input/SKILL.md deleted file mode 100644 index e1233833..00000000 --- a/.agents/skills/productize-opportunity-solution-tree-from-input/SKILL.md +++ /dev/null @@ -1,189 +0,0 @@ ---- -name: productize-opportunity-solution-tree-from-input -description: >- - Opportunity Solution Tree from input. Use when the user needs a product workflow for user - research related to opportunity solution tree from input. Trigger terms: user-research, ost, - continuous-discovery. ---- - - - -# Opportunity Solution Tree from input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `opportunity-solution-tree-from-input` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Opportunity Solution Tree from input research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Opportunity Solution Tree from input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- `{{business_outcome}}`: The business outcome the OST must support. -- `{{journey_nodes_as_list}}`: Ordered list of journey moments (for example: `["Add to calendar", "Edit calendar", "Review calendar"]`). -- `{{interview_transcripts_or_story_snippets}}`: Interview material with speaker labels and timestamps when available. -- `{{constraints_or_principles}}` (optional): Guardrails, principles, or constraints to respect. - - -GOAL -Transform interview evidence into a Teresa Torres-aligned Opportunity Solution Tree with distinct, properly nested opportunity nodes by journey moment. -Success metric: -- Output includes all required parts (A-E) with complete, internally consistent references. -- Opportunity nodes are user-need statements (not solutions), evidence-linked, and structurally valid. -- Prioritization is computable and traceable to interview evidence and `{{business_outcome}}`. - -CONSTRAINTS -- Use only provided inputs; if data is missing or ambiguous, state assumptions in Part E. -- Phrase opportunities from the end-user perspective. -- Assign each opportunity to exactly one primary moment from `{{journey_nodes_as_list}}`; if needed, list secondary moments in `alt_moments`. -- Enforce sibling distinctness: if two siblings cannot be pursued independently, merge or reframe. -- Enforce parent-child logic: solving a child must partially solve its parent. -- Remove generic parents that have only one specific child. -- Collapse duplicates into the clearest phrasing and preserve traceability. -- Keep opportunities specific when supported by quotes; keep general opportunities only when they organize multiple specific children. -- Include only opportunity nodes in the OST (no solutions). -- Preserve short supporting quotes and avoid introducing new facts not present in inputs. -- Use stable IDs and ensure all references resolve (`parent_id`, `duplicates_of`, `traceability`). - -FORMAT -Return all sections below in this exact order. - -Part A - Opportunity Inventory (Markdown Table) -- Include both parent and leaf opportunities. -- Use exactly these columns: -`| id | moment | opportunity_reframed (user-need) | parent_id | duplicates_of | representative_quotes | frequency_count | confidence (low/med/high) | alt_moments | notes/reframe_rationale |` -- `duplicates_of` is blank unless collapsed into another ID. - -Part B - Structured OST (Strict JSON in `` tags) -- Output must be wrapped exactly as: -`` -`{ ... }` -`` -- JSON schema: -```json -{ - "outcome": "{{business_outcome}}", - "moments": [ - { - "moment": "", - "tree": [ - { - "id": "A0", - "title": "", - "type": "opportunity", - "children": [] - } - ] - } - ], - "traceability": { - "A0": { - "quotes": ["..."], - "frequency_count": 1, - "confidence": "low" - } - } -} -``` -- Every node must include `id`, `title`, `type`, `children`. -- `type` must always be `"opportunity"`. -- Top-level moments must come from `{{journey_nodes_as_list}}`. -- JSON must be valid and parseable. - -Part C - Markdown Tree View (Human-readable) -- For each moment, render an indented opportunity tree: -`## ` -`- ` -` - ` -` - ` -- Include opportunities only (no solutions). - -Part D - Prioritized Leaf Backlog (Markdown Table) -- Include only leaf opportunities. -- Use exactly these columns: -`| id | moment | leaf_opportunity | impact (1-5) | frequency (1-5) | alignment_to_outcome (1-5) | priority_score | rationale |` -- Compute `priority_score = impact * frequency * alignment_to_outcome`. - -Part E - Assumptions & Open Questions -- Include: -- Uncertainties in placement/reframing. -- Potential missing siblings to test in future interviews. -- Ambiguities or contradictory evidence in quotes. -- Any hypotheses not supported by current interview evidence. - -FAILURE -- Any required part (A-E), required table column, or required JSON field is missing. -- JSON is malformed, non-parseable, or violates required schema/rules. -- Output includes solutions inside the OST opportunity tree. -- Opportunities are generic/overlapping and fail distinctness or parent-child logic. -- Claims are not traceable to interview evidence. -- IDs or references are inconsistent/unresolved. -- Priority scores are missing or incorrectly computed. -- Assumptions/ambiguities exist but are not explicitly listed in Part E. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `opportunity solution tree`, `ost`, `continuous discovery`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-opportunity-solution-tree-from-input/references/pm-skills-main-merge.md b/.agents/skills/productize-opportunity-solution-tree-from-input/references/pm-skills-main-merge.md deleted file mode 100644 index 61e905d3..00000000 --- a/.agents/skills/productize-opportunity-solution-tree-from-input/references/pm-skills-main-merge.md +++ /dev/null @@ -1,71 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to tighten OST outputs around desired outcome, opportunity branches, solution options, and experiments. - -## Routing Signals - -- opportunity solution tree -- ost -- continuous discovery - -## pm-product-discovery/skills/opportunity-solution-tree/SKILL.md - -## Opportunity Solution Tree (OST) - -A visual framework for structuring continuous product discovery. Connects a desired **outcome** to customer **opportunities**, possible **solutions**, and **experiments** to validate them. - -### Domain Context - -The **Opportunity Solution Tree** (Teresa Torres, *Continuous Discovery Habits*) is the backbone of modern product discovery. It prevents teams from jumping to solutions by forcing them to first map the opportunity space. - -**Structure (4 levels):** - -1. **Desired Outcome** (top) -- The measurable business or product outcome the team is pursuing. Should be a single, clear metric (e.g., "increase 7-day retention to 40%"). This comes from your OKRs or product strategy. - -2. **Opportunities** (second level) -- Customer needs, pain points, or desires discovered through research. These are problems worth solving -- not features. Frame them from the customer's perspective: "I struggle to..." or "I wish I could..." Prioritize using Opportunity Score: **Importance x (1 Satisfaction)** (Dan Olsen, *The Lean Product Playbook*). Normalize Importance and Satisfaction to 0-1. - -3. **Solutions** (third level) -- Possible ways to address each opportunity. Generate multiple solutions per opportunity -- don't commit to the first idea. The **Product Trio** (PM + Designer + Engineer) should ideate together. "Best ideas often come from engineers." - -4. **Experiments** (bottom) -- Fast, cheap tests to validate whether a solution actually addresses the opportunity. Use assumption testing (Value, Usability, Viability, Feasibility risks). Prefer experiments with "skin-in-the-game" (Alberto Savoia) over opinion-based validation. - -**Key principles:** - -- **One outcome at a time.** Don't try to solve everything. Focus the tree on a single desired outcome. -- **Opportunities, not features.** "Never allow customers to design solutions. Prioritize opportunities (problems), not features." -- **Compare and contrast.** Always generate at least 3 solutions per opportunity before choosing. Avoid the "first idea" trap. -- **Discovery is not linear.** Loop back if experiments fail. Kill solutions that don't validate. Explore new branches. -- **Continuous, not periodic.** Update the tree weekly as you learn from interviews, analytics, and experiments. - -### Instructions - -You are helping a product team build an Opportunity Solution Tree for **$ARGUMENTS**. - -### Input Requirements -- A desired outcome or business metric to improve -- Customer research data (interviews, surveys, analytics, feedback) -- Optionally: existing opportunities or solution ideas to organize - -### Process - -1. **Define the desired outcome** -- Confirm or help articulate a single, measurable outcome at the top of the tree. - -2. **Map opportunities** -- From provided research, identify 3-7 customer opportunities (needs/pains). Group related opportunities. Frame each from the customer's perspective. - -3. **Prioritize opportunities** -- Use Opportunity Score or qualitative assessment to rank. Focus on the top 2-3. - -4. **Generate solutions** -- For each prioritized opportunity, brainstorm 3+ solutions from PM, Designer, and Engineer perspectives. - -5. **Design experiments** -- For the most promising solutions, suggest 1-2 fast experiments. Specify: hypothesis, method, metric, success threshold. - -6. **Visualize the tree** -- Present the full OST in a clear hierarchical format. - -Think step by step. Save as markdown if substantial. - ---- - -### Further Reading - -- [The Extended Opportunity Solution Tree](https://www.productcompass.pm/p/the-extended-opportunity-solution-tree) -- [What Is Product Discovery? The Ultimate Guide Step-by-Step](https://www.productcompass.pm/p/what-exactly-is-product-discovery) -- [Product Trio: Beyond the Obvious](https://www.productcompass.pm/p/product-trio) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) diff --git a/.agents/skills/productize-outcome-roadmap/SKILL.md b/.agents/skills/productize-outcome-roadmap/SKILL.md deleted file mode 100644 index 31a9bfc3..00000000 --- a/.agents/skills/productize-outcome-roadmap/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-outcome-roadmap -description: >- - Outcome Roadmap. Use when converting a feature roadmap into an outcome roadmap, making - roadmap communication more strategic, or reframing initiatives around impact. ---- - - - -# Outcome Roadmap - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `outcome-roadmap` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Outcome-focused roadmap that rewrites feature work into user and business outcomes - -Use when converting a feature roadmap into an outcome roadmap, making roadmap communication more strategic, or reframing initiatives around impact. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Outcome-focused roadmap that rewrites feature work into user and business outcomes -- **Source method**: pm-skills-main/pm-execution/skills/outcome-roadmap/SKILL.md - -## Method - -## Purpose - -You are an experienced product manager helping $ARGUMENTS shift from output-focused roadmaps (which emphasize features) to outcome-focused roadmaps (which emphasize customer and business impact). This skill rewrites initiatives as outcome statements that inspire and measure what matters. - -## Context - -Output-focused roadmaps create false precision and misalign teams around features rather than results. Outcome-focused roadmaps clarify the customer problems being solved and the business value expected, enabling flexible execution and strategic thinking. - -## Instructions - -1. **Gather Information**: If the user provides a current roadmap, read it carefully. If they mention strategy documents or company objectives, use web search to understand how the roadmap should align with broader goals. - -2. **Think Step by Step**: - - For each initiative, ask: "What outcome are we trying to achieve?" - - What customer problem are we solving? - - What business metric will improve? - - How will this impact the customer experience or business? - - Is there a better, different way to achieve the same outcome? - -3. **Transformation Process**: For each initiative on the roadmap: - - **Identify the Output**: What feature or project is planned? - - **Uncover the Outcome**: Why are we building it? What changes for customers or business? - - **Rewrite as Outcome Statement**: Use this format: - ``` - Enable [customer segment] to [desired customer outcome] so that [business impact] - ``` - -4. **Example Transformation**: - - **Output (Old)**: Q2: Build advanced search filters, implement AI recommendations, redesign dashboard - - **Outcome (New)**: - - Q2: Enable customers to find products 50% faster through intuitive discovery - - Q2: Increase average order value by 20% through personalized AI recommendations - - Q2: Help operators monitor all systems with 80% reduction in dashboard load time - -5. **Structure Output**: Present the transformed roadmap with: - - Original initiatives listed by quarter/phase - - Outcome statements for each initiative - - Key metrics that will indicate success - - Dependencies or sequencing notes - -6. **Include Strategic Context**: For the overall roadmap, add: - - How outcomes align with company strategy - - Key assumptions about customer needs - - Flexible release windows (quarters, not specific dates) - -7. **Save the Output**: If substantial, save as a markdown document: `Outcome-Roadmap-[year].md` - -## Notes - -- An outcome should be testable and measurable -- Multiple outputs may achieve one outcome; focus on the outcome, not the feature list -- Outcome roadmaps are more resilient to change--embrace flexibility -- If unsure what outcome a feature drives, ask: "So what?" until you reach real customer/business value - ---- - -### Further Reading - -- [Product Vision vs Strategy vs Objectives vs Roadmap: The Advanced Edition](https://www.productcompass.pm/p/product-vision-strategy-goals-and) -- [Objectives and Key Results (OKRs) 101](https://www.productcompass.pm/p/okrs-101-advanced-techniques) -- [Business Outcomes vs Product Outcomes vs Customer Outcomes](https://www.productcompass.pm/p/business-outcomes-vs-product-outcomes) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-positioning-statements-from-competitive-analysis-and-value/SKILL.md b/.agents/skills/productize-positioning-statements-from-competitive-analysis-and-value/SKILL.md deleted file mode 100644 index 68036c07..00000000 --- a/.agents/skills/productize-positioning-statements-from-competitive-analysis-and-value/SKILL.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -name: productize-positioning-statements-from-competitive-analysis-and-value -description: >- - Positioning statements from competitive analysis and value proposition. Use when the user - needs a product workflow for product strategy related to positioning statements from - competitive analysis and value proposition. Trigger terms: marketing, positioning, - messaging, competitive-analysis, copywriting. ---- - - - -# Positioning statements from competitive analysis and value proposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `positioning-statements-from-competitive-analysis-and-value` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Positioning statements from competitive analysis and value proposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Positioning statements from competitive analysis and value proposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TARGET_CUSTOMER}} -- {{UNMET_NEEDS}} -- {{PRODUCT_NAME}} -- {{PRODUCT_CATEGORY}} -- {{BENEFITS}} -- {{COMPETITIVE_LANDSCAPE}} - - -GOAL -Produce a high-quality deliverable for: Positioning statements from competitive analysis and value proposition. -Success metric: -- Produces a canonical positioning statement plus two variants with clear differentiation. -- Uses outcomes over features, avoids buzzwords, and stays within length limits. -- Includes evidence hook and footnote for assumptions/prioritization when needed. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only the provided inputs; if any are missing or vague, infer minimally and wrap inferred text in [brackets]. -- Output must be a single Markdown code block and nothing else. -- Include exactly one canonical statement and two variants (Executive-readout, Sales enablement). -- Enforce length limits: canonical <= 60 words; variants <= 35 words each. -- Avoid hype/buzzwords (for example: revolutionary, cutting-edge). -- Include an evidence hook in Differentiation without fabricating data. -- If multiple segments/competitors are provided, choose one and note in a footnote. - -FORMAT -Return exactly this structure: - -```markdown -## Positioning Statement - -**For** [TARGET_CUSTOMER] -**who** [UNMET_NEEDS in one tight clause], -**[PRODUCT NAME]** **is a** [PRODUCT_CATEGORY] -**that** [BENEFITS as results the user achieves]. - -### Differentiation -**Unlike** [PRIMARY COMPETITOR / STATUS QUO], **[PRODUCT NAME]** **delivers** [outcome-focused differentiation + proof hook]. - ---- - -## Executive-Readout Variant -For [TARGET_CUSTOMER], **[PRODUCT NAME]** is a [PRODUCT_CATEGORY] that [top outcome]. Unlike [competitor/status quo], it [sharp differentiator]. - -## Sales Enablement Variant -When [TARGET_CUSTOMER] struggles with [UNMET_NEEDS], **[PRODUCT NAME]** helps them [BENEFITS]. Unlike [competitor/alternative], it [differentiator tied to buying criteria]. - -[Optional Footnote: one sentence noting assumptions or prioritization choices] -``` - -FAILURE -- Output is not a single Markdown code block. -- Canonical or variant statements exceed length limits. -- Differentiation lacks an evidence hook. -- Missing or incorrect sections/labels from the required format. -- Footnote is missing when assumptions or prioritization are made. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `value proposition statements`, `marketing copy`, `sales messaging`, `onboarding messages`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-positioning-statements-from-competitive-analysis-and-value/references/pm-skills-main-merge.md b/.agents/skills/productize-positioning-statements-from-competitive-analysis-and-value/references/pm-skills-main-merge.md deleted file mode 100644 index 97249401..00000000 --- a/.agents/skills/productize-positioning-statements-from-competitive-analysis-and-value/references/pm-skills-main-merge.md +++ /dev/null @@ -1,58 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source when a positioning or value proposition must be translated into channel-specific marketing, sales, or onboarding statements. - -## Routing Signals - -- value proposition statements -- marketing copy -- sales messaging -- onboarding messages - -## pm-marketing-growth/skills/value-prop-statements/SKILL.md - -Generate value proposition statements from existing value propositions for marketing, sales, and onboarding. Creates statements that address target segments, emphasize benefits, and highlight capabilities. Perfect for crafting targeted marketing content, sales presentations, and customer onboarding messages. - -## When to Use - -- Writing marketing copy and promotional content -- Creating sales decks and pitch materials -- Crafting customer onboarding messages -- Developing segment-specific messaging -- Triggers: value proposition statements, marketing copy, sales messaging, value statements, positioning copy - -## Prompt - -You are an experienced product growth expert with expertise in value proposition development and targeted messaging. - -Based on the following value proposition(s) for $ARGUMENTS, develop comprehensive value proposition statements that can be used across marketing, sales, and onboarding contexts. - -For each statement, ensure it: -- Directly addresses a specific target market segment or use case -- Emphasizes the primary benefit and desired outcome -- Highlights the key features and capabilities that make it possible -- Uses clear, compelling language that resonates with the audience - -## Example Framework (Canva) - -To illustrate the approach, here are value proposition statements for Canva: - -1. **For Social Media Marketers**: Canva empowers social media marketers to create stunning, on-brand designs effortlessly, without requiring expensive design software or hiring dedicated designers. Quickly produce professional-quality graphics that boost engagement and strengthen brand consistency across all channels. - -2. **For Small Business Owners**: With Canva's intuitive drag-and-drop interface and extensive collection of pre-designed templates, small business owners can launch polished marketing campaigns in minutes. Create website graphics, social posts, flyers, and promotional materials that look professionally designed--all without prior design experience. - -3. **For Content Creators**: By using Canva, content creators can focus on storytelling while spending less time on design logistics. Produce consistent, visually appealing content at scale with templates tailored to different platforms, ultimately allowing more time for audience engagement and content strategy. - -## Tips for Best Results - -- Provide existing value propositions or key benefits -- Specify target segments and their pain points -- Include product features and differentiators -- Share distribution channels (marketing, sales, onboarding) -- Mention any brand tone or voice guidelines - ---- - -### Further Reading - -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/.agents/skills/productize-pre-mortem/SKILL.md b/.agents/skills/productize-pre-mortem/SKILL.md deleted file mode 100644 index b6af7009..00000000 --- a/.agents/skills/productize-pre-mortem/SKILL.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -name: productize-pre-mortem -description: >- - Pre-Mortem. Use when stress-testing a PRD, launch plan, product bet, or feature before - execution or release. ---- - - - -# Pre-Mortem - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `pre-mortem` -- **Lifecycle**: Plan -- **Category**: Decision Making -- **Primary artifact**: Pre-mortem go/no-go decision report with failure modes, decision-making risk audit, mitigations, and recommendation - -Use when stress-testing a PRD, launch plan, product bet, or feature before execution or release. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Pre-mortem risk report with launch blockers, mitigations, and go/no-go checklist -- **Source method**: pm-skills-main/pm-execution/skills/pre-mortem/SKILL.md - -## Method - -## Purpose - -You are a veteran product manager conducting a pre-mortem analysis on $ARGUMENTS. This skill imagines launch failure and works backward to identify real risks, distinguish them from perceived worries, and create action plans to mitigate launch-blocking issues. - -## Context - -A pre-mortem is a structured risk-identification exercise that forces teams to think critically about what could go wrong before launch, when there's still time to act. By assuming failure, we surface hidden concerns and separate legitimate threats from overblown worries. - -Use this as a decision-making support skill for go/no-go, commit/defer, launch/hold, -continue/kill, and mitigation-priority decisions. It should improve the decision, not just -list risks. - -## Instructions - -1. **Gather the PRD**: If the user provides a PRD or product plan file, read it thoroughly. Understand the product, target market, key assumptions, and timeline. If relevant, use web search to research competitive landscape or market conditions. - -2. **Think Step by Step**: - - Imagine the product launches in 14 days - - Now imagine it fails--customers don't adopt it, revenue targets miss, reputation takes a hit - - What went wrong? - - What did we miss or not execute well? - - What were we overconfident about? - - What are we anchored to from the original plan? - - What would we stop doing if we ignored sunk cost? - - What evidence are we avoiding because it challenges the preferred launch story? - -3. **Categorize Risks**: Classify each potential failure as one of three types: - - **Tigers**: Real problems you personally see that could derail the project - - Based on evidence, past experience, or clear logic - - Should keep you awake at night - - Require action - - **Paper Tigers**: Problems others might worry about, but you don't believe in them - - Valid concerns on the surface, but unlikely or overblown - - Not worth significant resource investment - - Worth documenting to align stakeholders - - **Elephants**: Something you're not sure is a problem, but the team isn't discussing it enough - - Unspoken concerns or assumptions nobody is validating - - Could be real; you're unsure - - Deserve investigation before launch - -4. **Classify Tigers by Urgency**: - - **Launch-Blocking**: Must be solved before launch - - Example: Core feature broken, regulatory blocker, key customer dependency unmet - - **Fast-Follow**: Must be solved within 30 days post-launch - - Example: Performance issues, secondary features incomplete - - **Track**: Monitor post-launch; solve if it becomes an issue - - Example: Nice-to-have features, edge cases - -5. **Create Action Plans**: For every Launch-Blocking Tiger: - - Describe the risk clearly - - Suggest a concrete mitigation action - - Identify the best owner (function/person) - - Set a decision/completion date - -6. **Audit Decision-Making Risks**: - - Optimism bias: where the plan assumes success without enough evidence - - Sunk cost or escalation: where prior work may be keeping the team committed - - Anchoring: where an early scope, date, or metric may be driving the decision - - Confirmation: where evidence selection favors the preferred launch path - - Status quo: where "keep going" is treated as safer than changing course - - Role or group risk: where power, consensus, or function-level incentives suppress dissent - -7. **Structure Output**: Present the analysis as: - - ``` - ## Pre-Mortem Analysis: [Product Name] - - ### Tigers (Real Risks) - [List each real risk with category and mitigation plan] - - ### Paper Tigers (Overblown Concerns) - [List each, explain why it's not a true risk] - - ### Elephants (Unspoken Worries) - [List each, recommend investigation approach] - - ### Action Plans for Launch-Blocking Tigers - [For each, include: Risk, Mitigation, Owner, Due Date] - - ### Decision-Making Risk Audit - [Optimism, sunk cost, anchoring, confirmation, status quo, and role/group risks] - - ### Decision Recommendation - [Go / hold / defer / reduce scope / run validation first, with confidence and review date] - ``` - -8. **Save the Output**: Save as a markdown document: `PreMortem-[product-name]-[date].md` - -## Notes - -- Be honest and constructive--the goal is to improve launch readiness, not assign blame -- Default to "Tiger" if unsure; it's better to address risks early -- Involve cross-functional perspectives (engineering, design, go-to-market) in your analysis -- Revisit the pre-mortem 2-3 weeks before launch to verify mitigations are on track - ---- - -### Further Reading - -- [How Meta and Instagram Use Pre-Mortems to Avoid Post-Mortems](https://www.productcompass.pm/p/how-to-run-pre-mortem-template) -- [How to Manage Risks as a Product Manager](https://www.productcompass.pm/p/how-to-manage-risks-as-a-product-manager) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-pricing-strategy/SKILL.md b/.agents/skills/productize-pricing-strategy/SKILL.md deleted file mode 100644 index 4f97ed0a..00000000 --- a/.agents/skills/productize-pricing-strategy/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: productize-pricing-strategy -description: >- - Pricing Strategy. Use when setting price, changing packaging, comparing pricing models, - evaluating freemium versus paid, or designing pricing experiments. ---- - - - -# Pricing Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `pricing-strategy` -- **Lifecycle**: Strategize -- **Category**: Business Model -- **Primary artifact**: Pricing strategy brief with model, package logic, willingness-to-pay assumptions, and validation plan - -Use when setting price, changing packaging, comparing pricing models, evaluating freemium versus paid, or designing pricing experiments. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: Growth -- **Primary artifact**: Pricing strategy brief with model, package logic, willingness-to-pay assumptions, and validation plan -- **Source method**: pm-skills-main/pm-product-strategy/skills/pricing-strategy/SKILL.md - -## Method - -## Pricing Strategy - -Design a pricing strategy grounded in value delivery, competitive positioning, and willingness to pay. - -### Context - -You are developing a pricing strategy for **$ARGUMENTS**. - -If the user provides files (competitor pricing, survey data, financial models, or usage data), read them first. Use web search to research competitor pricing if needed. - -### Instructions - -1. **Understand the value delivered**: - - What is the core value proposition? - - What is the customer's alternative (and its cost)? - - What quantifiable outcomes does the product deliver? (time saved, revenue gained, cost reduced) - - What is the customer's willingness to pay based on that value? - -2. **Evaluate pricing models** -- recommend the best fit: - - | Model | Best For | Example | - |---|---|---| - | **Flat-rate** | Simple products, predictable costs | Basecamp ($99/mo flat) | - | **Per-seat** | Collaboration tools, team products | Slack, Figma | - | **Usage-based** | Infrastructure, API products | AWS, Twilio | - | **Tiered** | Products with distinct user segments | Most SaaS (Free/Pro/Enterprise) | - | **Freemium** | Products with viral/network effects | Spotify, Notion | - | **Freemium + usage** | Platform products | Vercel, OpenAI API | - | **Value-based** | High-impact enterprise tools | Salesforce, Palantir | - -3. **Analyze competitive pricing**: - - Map competitor pricing tiers and what's included - - Identify where your product sits (premium, mid-market, budget) - - Find pricing gaps or opportunities - - Note any industry pricing conventions - -4. **Design the pricing structure**: - - **Tiers**: Define 2-4 tiers with clear differentiation - - **Feature gating**: Which features go in which tier? (Use value metrics, not arbitrary limits) - - **Value metric**: What unit do you charge on? (users, events, storage, API calls) - - **Anchor pricing**: Set the most popular tier to feel like the obvious choice - - **Annual discount**: Typically 15-20% off monthly pricing - -5. **Estimate price sensitivity**: - - Van Westendorp Price Sensitivity Meter (if survey data available): - - Too cheap -> quality concerns - - Cheap -> good value - - Expensive -> starting to hesitate - - Too expensive -> won't buy - - Alternatively, estimate based on competitor pricing and value delivered - -6. **Plan pricing experiments**: - - A/B test pricing pages (different price points, tier names, feature bundles) - - Founder-led sales conversations to test willingness to pay - - Landing page tests with different price anchors - - Cohort analysis of conversion rates by price point - -7. **Output a pricing recommendation**: - ``` - Recommended Model: [Model type] - Value Metric: [What you charge on] - - | Tier | Price | Target Segment | Key Features | Positioning | - |---|---|---|---|---| - - Key Assumptions: - - [Assumption] -> [How to test] - - Risks: - - [Risk] -> [Mitigation] - ``` - -Think step by step. Save as markdown. Flag any assumptions that need validation before launch. - ---- - -### Further Reading - -- [Product Pricing Strategies 101](https://www.productcompass.pm/p/product-pricing-strategies-101) -- [The AI Product Pricing Masterclass: OpenAI Product Lead on Why SaaS Pricing Fails in AI (and How to Fix It)](https://www.productcompass.pm/p/ai-product-pricing) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-prioritization-frameworks/SKILL.md b/.agents/skills/productize-prioritization-frameworks/SKILL.md deleted file mode 100644 index ab0beb21..00000000 --- a/.agents/skills/productize-prioritization-frameworks/SKILL.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -name: productize-prioritization-frameworks -description: >- - Prioritization Frameworks. Use when selecting or comparing prioritization frameworks such as - RICE, ICE, Kano, MoSCoW, Opportunity Score, cost of delay, or impact-effort. ---- - - - -# Prioritization Frameworks - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `prioritization-frameworks` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Prioritization framework recommendation with scoring template and decision rationale - -Use when selecting or comparing prioritization frameworks such as RICE, ICE, Kano, MoSCoW, Opportunity Score, cost of delay, or impact-effort. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: none -- **Primary artifact**: Prioritization framework recommendation with scoring template and decision rationale -- **Source method**: pm-skills-main/pm-execution/skills/prioritization-frameworks/SKILL.md - -## Method - -## Prioritization Frameworks Reference - -A reference guide to help you select and apply the right prioritization framework for your context. - -### Core Principle - -Never allow customers to design solutions. Prioritize **problems (opportunities)**, not features. - -### Opportunity Score (Dan Olsen, *The Lean Product Playbook*) - -The recommended framework for prioritizing customer problems. - -Survey customers on **Importance** and **Satisfaction** for each need (normalize to 0-1 scale). - -Three related formulas: -- **Current value** = Importance x Satisfaction -- **Opportunity Score** = Importance x (1 Satisfaction) -- **Customer value created** = Importance x (S2 S1), where S1 = satisfaction before, S2 = satisfaction after - -High Importance + low Satisfaction = highest Opportunity Score = best opportunities. Plot on an Importance vs Satisfaction chart -- upper-left quadrant is the sweet spot. Prioritizes customer problems, not solutions. - -### ICE Framework - -Useful for prioritizing initiatives and ideas. Considers not only value but also risk and economic factors. - -- **I** (Impact) = Opportunity Score x Number of Customers affected -- **C** (Confidence) = How confident are we? (1-10). Accounts for risk. -- **E** (Ease) = How easy is it to implement? (1-10). Accounts for economic factors. - -**Score** = I x C x E. Higher = prioritize first. - -### RICE Framework - -Splits ICE's Impact into two separate factors. Useful for larger teams that need more granularity. - -- **R** (Reach) = Number of customers affected -- **I** (Impact) = Opportunity Score (value per customer) -- **C** (Confidence) = How confident are we? (0-100%) -- **E** (Effort) = How much effort to implement? (person-months) - -**Score** = (R x I x C) / E - -### 9 Frameworks Overview - -| Framework | Best For | Key Insight | -|-----------|----------|-------------| -| Eisenhower Matrix | Personal tasks | Urgent vs Important -- for individual PM task management | -| Impact vs Effort | Tasks/initiatives | Simple 2x2 -- quick triage, not rigorous for strategic decisions | -| Risk vs Reward | Initiatives | Like Impact vs Effort but accounts for uncertainty | -| **Opportunity Score** | Customer problems | **Recommended.** Importance x (1 Satisfaction). Normalize to 0-1. | -| Kano Model | Understanding expectations | Must-be, Performance, Attractive, Indifferent, Reverse. For understanding, not prioritizing. | -| Weighted Decision Matrix | Multi-factor decisions | Assign weights to criteria, score each option. Useful for stakeholder buy-in. | -| **ICE** | Ideas/initiatives | Impact x Confidence x Ease. Recommended for quick prioritization. | -| **RICE** | Ideas at scale | (Reach x Impact x Confidence) / Effort. Adds Reach to ICE. | -| MoSCoW | Requirements | Must/Should/Could/Won't. Caution: project management origin. | - -### Templates - -- [Opportunity Score intro (PDF)](https://drive.google.com/file/d/1ENbYPmk1i1AKO7UnfyTuULL5GucTVufW/view) -- [Importance vs Satisfaction Template -- Dan Olsen (Google Slides)](https://docs.google.com/presentation/d/1jg-LuF_3QHsf6f1nE1f98i4C0aulnRNMOO1jftgti8M/edit#slide=id.g796641d975_0_3) -- [ICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1LUfnsPolhZgm7X2oij-7EUe0CJT-Dwr-/edit?usp=share_link&ouid=111307342557889008106&rtpof=true&sd=true) -- [RICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1S-6QpyOz5MCrV7B67LUWdZkAzn38Eahv/edit?usp=sharing&ouid=111307342557889008106&rtpof=true&sd=true) - ---- - -### Further Reading - -- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium) -- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-privacy-policy/SKILL.md b/.agents/skills/productize-privacy-policy/SKILL.md deleted file mode 100644 index c5f229e5..00000000 --- a/.agents/skills/productize-privacy-policy/SKILL.md +++ /dev/null @@ -1,323 +0,0 @@ ---- -name: productize-privacy-policy -description: >- - Privacy Policy. Use when drafting or updating a privacy policy for a product, launch, - website, app, or customer-facing workflow. ---- - - - -# Privacy Policy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `privacy-policy` -- **Lifecycle**: Launch & Learn -- **Category**: Operations -- **Primary artifact**: Privacy policy draft for legal review with data practices, assumptions, and compliance flags - -Use when drafting or updating a privacy policy for a product, launch, website, app, or customer-facing workflow. - -## Productize Contract - -- **Primary lifecycle**: Launch & Learn -- **Supporting lifecycle**: none -- **Primary artifact**: Privacy policy draft for legal review with data practices, assumptions, and compliance flags -- **Source method**: pm-skills-main/pm-toolkit/skills/privacy-policy/SKILL.md - -## Legal Review Guardrail - -This skill creates a product/legal working draft for review. Do not present the output as legal advice or final compliance approval. Flag jurisdiction, data, party, and policy assumptions for qualified review. - -## Method - -You are an experienced data privacy and compliance specialist. Your role is to help draft comprehensive, clear, and compliant privacy policies for digital products and services. - -## Purpose -Draft a detailed privacy policy for a product or service. The policy covers data types handled, applicable jurisdiction, and clearly marks clauses that require legal review. Provide plain-language explanations to ensure accessibility and transparency. - -## Important Disclaimer -**This is for informational purposes only and does not constitute legal advice. Always have a qualified attorney specializing in data privacy law review the final policy before publication. Privacy policies are legally binding documents that establish your company's responsibilities and users' rights; professional legal review is essential.** - -## Input Arguments -- `$PRODUCT_NAME`: Name of the product or service -- `$PRODUCT_URL`: URL or description of the product (optional; will be researched if provided) -- `$COMPANY_NAME`: Legal name of your company -- `$COMPANY_ADDRESS`: Company headquarters or registered address -- `$CONTACT_EMAIL`: Email for privacy inquiries (e.g., privacy@company.com) -- `$INFORMATION_TYPES`: Types of data collected (e.g., "names, emails, usage behavior, location data, payment information, device identifiers") -- `$JURISDICTION`: Applicable jurisdiction (e.g., "United States," "European Union (GDPR)," "California (CCPA)") - -## Process - -### Step 1: Research (if URL provided) -If $PRODUCT_URL is provided: -- Visit the product website -- Identify what data is collected (forms, tracking, login, payments) -- Note any third-party integrations (analytics, payment processors, SDKs) -- Understand the product's primary features and use cases - -### Step 2: Clarify Data Collection -Map out all data your product collects: -- **Direct collection**: What users enter (name, email, preferences) -- **Automatic collection**: What is tracked (IP address, usage behavior, device info, cookies) -- **Third-party data**: What comes from partners, integrations, or service providers -- **Special categories**: Does the product handle health data, financial data, children's data, biometric data? - -### Step 3: Identify Applicable Laws -Note which laws apply: -- **GDPR** (EU users): Stricter; requires explicit consent, data subject rights, DPA -- **CCPA/CPRA** (California): Consumer rights to access, delete, opt-out -- **Other US states**: Laws like VIPA, TDPSA emerging -- **Industry-specific**: HIPAA (health), GLBA (finance), FERPA (education) -- Determine if your product serves international users - -### Step 4: Structure the Privacy Policy -Organize in standard sections (detailed below). - -### Step 5: Use Plain Language -Write clearly and accessibly. Avoid technical jargon. Define terms when first used. Help users understand what data you collect and why. - -### Step 6: Highlight Areas Needing Legal Review -Mark sections with [ LEGAL REVIEW REQUIRED] where jurisdiction-specific language, specific data rights, or legal clauses are needed. - -### Step 7: Provide Context -Include notes explaining: -- Why each section is important -- What decisions the company must make -- Compliance considerations - -## Privacy Policy Template Structure - -### Preamble -A brief introduction explaining: -- What the policy covers -- When it was last updated -- How users can contact you with questions - -### Key Sections - -#### 1. Information We Collect -Categories of data: -- Personal information (name, email, account info) -- Usage data (pages viewed, features used, time spent) -- Device information (type, OS, browser, IP address) -- Location data (if applicable) -- Payment information (handled securely, often by third parties) -- Communications (if users contact support) -- [ LEGAL REVIEW REQUIRED] Sensitive or special categories (health, biometric, etc.) - -#### 2. How We Collect Information -Methods: -- Directly from users (forms, registration, preferences) -- Automatically (cookies, analytics, device sensors) -- From third parties (partners, service providers, data brokers) - -#### 3. How We Use Information -Purposes (be specific, not vague): -- Providing the service and customer support -- Improving and personalizing the product -- Analytics and understanding user behavior -- Marketing and promotional communications -- Security and fraud prevention -- Legal compliance -- [ LEGAL REVIEW REQUIRED] Other purposes (must be explicitly stated if you plan to use data for new purposes later) - -#### 4. Legal Basis for Processing -[ LEGAL REVIEW REQUIRED] Especially important for GDPR: -- **Consent**: User has explicitly agreed -- **Contract**: Data is needed to provide the service -- **Legal obligation**: Law requires processing -- **Vital interests**: Protection of life or health -- **Public task**: Part of your official function -- **Legitimate interests**: Company has a legitimate business need - -#### 5. Data Sharing and Third Parties -Who has access to data: -- Service providers (hosting, analytics, email, payments) -- Business partners (if applicable) -- Legal authorities (if required by law) -- [ LEGAL REVIEW REQUIRED] Where third parties are located (especially if outside user's jurisdiction) - -#### 6. International Data Transfer -[ LEGAL REVIEW REQUIRED] If applicable: -- How data is transferred across borders -- Mechanisms used (Standard Contractual Clauses, adequacy decisions, user consent) -- Where data is stored and processed - -#### 7. Data Retention -How long you keep data: -- Account data: As long as account is active, then X months/years -- Usage logs: X months -- Deleted content: Y days before permanent deletion -- [ LEGAL REVIEW REQUIRED] Be specific, not vague; many regulations require this - -#### 8. User Rights -[ LEGAL REVIEW REQUIRED] Varies by jurisdiction: -- **Right to access**: Users can request copy of their data -- **Right to deletion**: Users can request data be deleted ("right to be forgotten") -- **Right to correct**: Users can update inaccurate data -- **Right to restrict processing**: Users can limit how data is used -- **Right to data portability**: Users can download their data -- **Right to opt-out**: Users can unsubscribe from marketing -- **Right to lodge complaints**: Users can contact data protection authorities -- How users exercise these rights (contact info, process) - -#### 9. Cookies and Tracking -[ LEGAL REVIEW REQUIRED] Detailed info: -- What cookies and tracking tools are used -- Why each is used (functionality, analytics, marketing) -- How to manage/disable cookies -- Whether explicit consent is required (GDPR requires it for non-essential cookies) - -#### 10. Security -Measures taken to protect data: -- Encryption in transit and at rest -- Access controls and authentication -- Regular security audits -- Incident response procedures -- Limitations (no system is 100% secure) - -#### 11. Children's Privacy -[ LEGAL REVIEW REQUIRED] If product serves users under 13: -- Parental consent mechanisms -- Age gates or verification -- Compliance with COPPA (US), UK Children's Code, similar laws - -#### 12. Contact and Rights -How users contact you: -- Privacy contact email -- Mailing address -- Response timeframe for requests -- Data Protection Officer (if required) - -#### 13. Policy Changes -How you'll communicate changes: -- Notice period (e.g., 30 days) -- How you'll notify (email, in-app, website) -- User's ability to opt-out if changes are material - -#### 14. Additional Provisions -- **No sale of data**: Whether you sell/share data (if not, explicitly state) -- **Third-party links**: You're not responsible for external sites -- **Governing law**: Which jurisdiction's laws govern -- **Effective date**: When policy became active - ---- - -## Content Guidelines - -- **Be specific**: Don't say "we use your data for product improvement"; say "we analyze usage patterns to identify features that users find confusing and prioritize improvements to those features" -- **Plain language**: Write for a general audience, not lawyers. Explain what data you collect and why in simple terms -- **Transparency**: Be honest about all data collection, including analytics, third parties, and uses -- **User control**: Explain how users can access, delete, or opt-out of data processing -- **Align with practice**: The policy must match what your product actually does; if it doesn't, change the product or the policy -- **Complete information types**: Use $INFORMATION_TYPES to make the policy specific to your actual data collection - ---- - -## Output Format - -Present the privacy policy in three parts: - -### Part 1: Summary -Quick reference: -- Product name and purpose -- Data types collected -- Jurisdiction(s) covered -- Key user rights -- Retention periods -- Contact information - -### Part 2: Full Privacy Policy Document -A complete, ready-to-publish privacy policy. - -### Part 3: Customization and Compliance Notes -Guidance on: -- Sections marked for legal review -- Jurisdiction-specific considerations (GDPR, CCPA, etc.) -- Compliance checklist -- Common modifications based on product type -- Next steps (legal review, implementation, user communication) - ---- - -## Key Compliance Reminders - -- **GDPR compliance** (if serving EU users): Requires explicit consent, clear rights, DPA with processors, DPIA for risky processing -- **CCPA/CPRA** (California users): Requires rights to access, delete, opt-out; detailed disclosures; no discrimination for exercising rights -- **Transparency**: Users must understand what data is collected, how it's used, and who can access it -- **Accuracy**: Keep your policy updated as data practices change -- **Enforcement**: Privacy violations can result in fines, user lawsuits, and reputational damage -- **Get legal review**: Before publishing, have a data privacy attorney in your jurisdiction review the policy - ---- - -## Before You Publish - -- [ ] Have a data privacy attorney review the policy -- [ ] Ensure the policy matches your actual data collection and use -- [ ] Make privacy request processes easy for users (accessible contact info, quick response) -- [ ] Implement technical measures mentioned in the policy (encryption, access controls, etc.) -- [ ] Set up systems to handle data subject rights requests (access, deletion, etc.) -- [ ] Document your legal basis for each type of processing -- [ ] Have a Data Processing Agreement (DPA) with all third-party processors -- [ ] Notify users of material changes; consider giving them a choice to opt-out - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-product-vision/SKILL.md b/.agents/skills/productize-product-vision/SKILL.md deleted file mode 100644 index 41a65c28..00000000 --- a/.agents/skills/productize-product-vision/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: productize-product-vision -description: >- - Product Vision. Use when defining, sharpening, or stress-testing a product vision that needs - to motivate teams and align stakeholders. ---- - - - -# Product Vision - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `product-vision` -- **Lifecycle**: Strategize -- **Category**: Stakeholder Communication -- **Primary artifact**: Product Vision strategy memo with choices, tradeoffs, risks, and recommended next move - -Use when defining, sharpening, or stress-testing a product vision that needs to motivate teams and align stakeholders. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: Align -- **Primary artifact**: Product vision statement with audience, future state, strategic principles, and alignment notes -- **Source method**: pm-skills-main/pm-product-strategy/skills/product-vision/SKILL.md - -## Method - -## Metadata -- **Name**: product-vision -- **Description**: Brainstorm an inspiring, achievable, and emotional product vision. Use when defining or refining product vision, aligning teams around a north star, or creating a vision statement. -- **Triggers**: product vision, vision statement, create vision, inspiring vision, north star vision - -### Domain Context - -A product **vision** answers: "How can we inspire people? What are we aspiring to achieve? What values do we uphold?" Vision evolves with strategy -- it's a living statement, not a one-time exercise. It should make people feel something, not just understand the direction. - -## Instructions - -You are a veteran product leader developing a compelling product vision. - -Your task is to brainstorm a product vision for $ARGUMENTS. - -## Input Requirements -- Information about your company and product (you may read files from the user's workspace) -- Current state, market positioning, or any relevant context - -## Output -Provide a vision statement that is: -1. **Inspiring** - Motivates teams to wake up and commit to the goal -2. **Achievable** - Realistic based on resources, market, and capabilities -3. **Emotional** - Creates meaning and connection - -## Process -1. Review provided company and product information -2. Identify the core problem being solved -3. Envision the ideal future state for customers and the company -4. Draft multiple vision options (3-5 variations) -5. Select the strongest vision and briefly explain your rationale -6. Highlight how this vision aligns with company values and market opportunity - -## Notes -- A great vision is memorable and can be communicated in one sentence -- Balance ambition with credibility -- Consider the perspective of customers, employees, and investors -- Avoid jargon; use clear, emotionally resonant language - ---- - -### Further Reading - -- [Product Vision vs Strategy vs Objectives vs Roadmap: The Advanced Edition](https://www.productcompass.pm/p/product-vision-strategy-goals-and) -- [Introducing the Product Strategy Canvas](https://www.productcompass.pm/p/new-product-strategy-canvas) -- [From Strategy to Objectives Masterclass](https://www.productcompass.pm/p/product-vision-strategy-objectives-course) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-proto-persona-profiles-from-user-research-and-market-data/SKILL.md b/.agents/skills/productize-proto-persona-profiles-from-user-research-and-market-data/SKILL.md deleted file mode 100644 index 17f09fbf..00000000 --- a/.agents/skills/productize-proto-persona-profiles-from-user-research-and-market-data/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: productize-proto-persona-profiles-from-user-research-and-market-data -description: >- - Proto-persona profiles from user research and market data. Use when the user needs a product - workflow for user research related to proto-persona profiles from user research and market - data. Trigger terms: user-research, personas, ux. ---- - - - -# Proto-persona profiles from user research and market data - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `proto-persona-profiles-from-user-research-and-market-data` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Proto-persona profiles from user research and market data research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Proto-persona profiles from user research and market data**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- `{{USER_RESEARCH}}`: Interview notes, quotes, observations, transcripts. -- `{{MARKET_DATA}}`: Segment size, competitors, market trends. -- `{{BEHAVIORAL_INSIGHTS}}`: Analytics, JTBD signals, usage patterns. -- `{{DEMOGRAPHICS}}`: Age, location, income, education, and related profile context. -- `{{CONSTRAINTS}}` (optional): Industry, region, compliance, accessibility constraints. -- `{{PREFERENCES}}` (optional): `tone`, `depth` (`brief|standard|deep`), `number_of_personas` (default `1`). - - -GOAL -Synthesize mixed research inputs into concise, evidence-linked proto-persona profile(s) ready for early product decisions and validation. -Success metric: -- Persona profiles are internally consistent and clearly distinguish evidence from assumptions. -- Each profile includes confidence, explicit unknowns, and prioritized probing questions. -- Output follows required markdown canvas structure exactly. - -CONSTRAINTS -- Use only provided inputs; if data is missing, write `TBD` and cover it in Probing Questions. -- Extract concrete signals first (quotes, facts, metrics), then synthesize into pains/goals/behaviors. -- Clearly mark each claim as evidence-based or assumption with confidence (`High|Med|Low`). -- Use bracketed source tags (for example: `[UR#3]`, `[GA]`, `[MD]`) wherever evidence is cited. -- Avoid demographic stereotyping; unsupported demographics must be `TBD` or explicit assumptions. -- Ensure behaviors are observable and distinct from goals. -- If `number_of_personas > 1`, output distinct personas. -- Output markdown only; no JSON, XML, or HTML. -- Keep each persona under 400 words unless `depth = deep`. - -FORMAT -- Return one markdown code block per persona. -- Inside each code block, render exactly this structure: - -```markdown -# Proto Persona: {{Alliterative Name}} - -## Bio & Demographics -- Age: {{x-y}}, Location: {{region/city}}, Education: {{...}} -- Role/Status: {{job title or life stage}} -- Income/Spending Power: {{range or TBD}} -- Household/Partner Status: {{...}} -- Digital/Channel Habits: {{top channels/devices}} -- Leisure & Interests: {{...}} -- Notable Constraints: {{time, budget, compliance, accessibility}} - -## Representative Quotes -- "{{quote}}" - [{{source tag}}] -- "{{quote}}" - [{{source tag}}] -- "{{quote}}" - [{{source tag}}] - -## Pains -- {{pain statement}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## What They're Trying to Accomplish (Behaviors & JTBD) -- {{job story or observed behavior}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## Goals -- {{goal}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## Attitudes & Influences -- **Decision-Making Authority:** {{buyer|user|champion|blocker|none}} [{{confidence}}] -- **Decision Influencers:** {{roles/peers/communities}} [{{confidence}}] -- **Beliefs & Attitudes:** {{heuristics, risk posture, trust signals}} [{{confidence}}] - -## Purchasing & Adoption Signals (Optional) -- Triggers: {{events that start the search}} -- Selection Criteria: {{top 3 decision criteria}} -- Objections: {{anticipated blockers}} -- Success Metrics: {{how they judge value}} - -## Accessibility & Inclusion (Optional) -- Considerations: {{access, language, bandwidth, cognitive load}} - -## Evidence & Confidence Summary -- Evidence Sources: {{list with counts, e.g., UR:6, GA:1, MD:2}} -- Assumptions: {{key assumptions}} -- Overall Confidence: {{High|Med|Low}} - {{1-2 sentence rationale}} - -## Probing Questions (Prioritized) -1. {{highest-value unknown}} -2. {{next unknown}} -3. {{next unknown}} -``` - -FAILURE -- Output is not markdown code block(s), or required persona section headings are missing. -- `number_of_personas > 1` is requested but personas are not distinct or separated. -- Quotes/sources do not support key pains, goals, or JTBD claims. -- Claims are untagged (missing evidence/assumption + confidence + source markers). -- `TBD`/low-confidence gaps are not reflected in prioritized probing questions. -- Content exceeds 400 words per persona when `depth` is not `deep`. -- Output includes JSON/XML/HTML or generic filler not grounded in provided inputs. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `user personas`, `proto persona`, `persona from research`, `segment profiles`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-proto-persona-profiles-from-user-research-and-market-data/references/pm-skills-main-merge.md b/.agents/skills/productize-proto-persona-profiles-from-user-research-and-market-data/references/pm-skills-main-merge.md deleted file mode 100644 index 35bcc9d0..00000000 --- a/.agents/skills/productize-proto-persona-profiles-from-user-research-and-market-data/references/pm-skills-main-merge.md +++ /dev/null @@ -1,75 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to sharpen persona profiles with JTBD, pains, gains, segment traits, unexpected insights, and decision implications. - -## Routing Signals - -- user personas -- proto persona -- persona from research -- segment profiles - -## pm-market-research/skills/user-personas/SKILL.md - -## Purpose -Create detailed, actionable user personas from research data that capture the true diversity of your user base. This skill generates research-backed personas with jobs-to-be-done, pain points, desired outcomes, and unexpected behavioral insights to guide product decisions. - -## Instructions - -You are an experienced product researcher specializing in persona development and user research synthesis. - -### Input -Your task is to create 3 refined user personas for **$ARGUMENTS**. - -If the user provides CSV, Excel, survey responses, interview transcripts, or other research data files, read and analyze them directly using available tools. Extract key patterns, demographics, motivations, and behaviors. - -### Analysis Steps (Think Step by Step) - -1. **Data Collection**: Read and review all provided research data and documents -2. **Pattern Recognition**: Identify recurring characteristics, goals, pain points, and behaviors across users -3. **Segmentation**: Group similar users into distinct personas based on shared motivations and jobs-to-be-done -4. **Enrichment**: For each persona, synthesize data into a coherent profile -5. **Validation**: Cross-reference insights to ensure personas are grounded in actual research findings - -### Output Structure - -For each of the 3 personas, provide: - -**Persona Name & Demographics** -- Age range, role/title, company size (if B2B), key characteristics - -**Primary Job-to-be-Done** -- The core outcome the persona is trying to achieve -- Context and frequency of the job - -**Top 3 Pain Points** -- Specific challenges or obstacles preventing job completion -- Impact and severity of each pain - -**Top 3 Desired Gains** -- Benefits, outcomes, or solutions the persona seeks -- How they measure success - -**One Unexpected Insight** -- A counterintuitive behavioral pattern or motivation derived from the data -- Why this matters for product decisions - -**Product Fit Assessment** -- How $ARGUMENTS addresses (or could address) this persona's needs -- Potential friction points or unmet needs - -## Best Practices - -- Ground all insights in actual data; avoid assumptions -- Use direct quotes from research when available -- Identify behavioral patterns, not just demographic categories -- Make personas distinct and non-overlapping where possible -- Flag any data gaps or areas requiring additional research - ---- - -### Further Reading - -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [Jobs-to-be-Done Masterclass with Tony Ulwick and Sabeen Sattar](https://www.productcompass.pm/p/jobs-to-be-done-masterclass-with) (video course) diff --git a/.agents/skills/productize-release-notes/SKILL.md b/.agents/skills/productize-release-notes/SKILL.md deleted file mode 100644 index 56a863d6..00000000 --- a/.agents/skills/productize-release-notes/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: productize-release-notes -description: >- - Release Notes. Use when turning tickets, PRDs, changelogs, or shipped work into clear - user-facing release notes or product update copy. ---- - - - -# Release Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `release-notes` -- **Lifecycle**: Launch & Learn -- **Category**: Delivery -- **Primary artifact**: Release Notes launch learning report with release evidence, feedback, decision, and next iteration - -Use when turning tickets, PRDs, changelogs, or shipped work into clear user-facing release notes or product update copy. - -## Productize Contract - -- **Primary lifecycle**: Launch & Learn -- **Supporting lifecycle**: Align -- **Primary artifact**: User-facing release notes organized by features, improvements, fixes, and user value -- **Source method**: pm-skills-main/pm-execution/skills/release-notes/SKILL.md - -## Method - -## Release Notes Generator - -Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes. - -### Context - -You are writing release notes for **$ARGUMENTS**. - -If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience. - -### Instructions - -1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract: - - What changed (feature, improvement, or fix) - - Who it affects (which user segment) - - Why it matters (the user benefit) - -2. **Categorize changes**: - - **New Features**: Entirely new capabilities - - **Improvements**: Enhancements to existing features - - **Bug Fixes**: Issues resolved - - **Breaking Changes**: Anything that requires user action (migrations, API changes) - - **Deprecations**: Features being sunset - -3. **Write each entry** following these principles: - - Lead with the user benefit, not the technical change - - Use plain language -- avoid jargon, internal codenames, or ticket numbers - - Keep each entry to 1-3 sentences - - Include visuals or screenshots if the user provides them - - **Example transformations**: - - Technical: "Implemented Redis caching layer for dashboard API endpoints" - - User-facing: "Dashboards now load up to 3x faster, so you spend less time waiting and more time analyzing." - - - Technical: "Fixed race condition in concurrent checkout flow" - - User-facing: "Fixed an issue where some orders could fail during high-traffic periods." - -4. **Structure the release notes**: - - ``` - # [Product Name] -- [Version / Date] - - ## New Features - - **[Feature name]**: [1-2 sentence description of what it does and why it matters] - - ## Improvements - - **[Area]**: [What got better and how it helps] - - ## Bug Fixes - - Fixed [issue description in user terms] - - ## Breaking Changes (if any) - - **Action required**: [What users need to do] - ``` - -5. **Adjust tone** to match the product's voice -- professional for B2B, friendly for consumer, developer-focused for APIs. - -Save as a markdown document. If the user wants HTML or another format, convert accordingly. - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-stakeholder-power-interest-and-influence-map/SKILL.md b/.agents/skills/productize-stakeholder-power-interest-and-influence-map/SKILL.md deleted file mode 100644 index 59a8efd3..00000000 --- a/.agents/skills/productize-stakeholder-power-interest-and-influence-map/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: productize-stakeholder-power-interest-and-influence-map -description: >- - Stakeholder Powerโ€“Interest & Influence Map. Use when the user needs a product workflow for - stakeholder management related to stakeholder powerโ€“interest & influence map. Trigger terms: - stakeholder-management, influence, internal-politics, communication. ---- - - - -# Stakeholder Powerโ€“Interest & Influence Map - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `stakeholder-power-interest-and-influence-map` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Stakeholder decision influence map with power-interest matrix, influence pyramid, role identity risks, engagement plan, and mitigations - -Use this skill to run the Productize prompt contract for **Stakeholder Powerโ€“Interest & Influence Map**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Stakeholder Powerโ€“Interest & Influence Map". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a stakeholder strategy output from initiative context and stakeholder details. -- If critical stakeholder context is missing, ask exactly 3 targeted questions; if still unclear, state assumptions and proceed. -- Produce: -- A Power-Interest 2x2 matrix with named stakeholders per quadrant. -- An Influence Pyramid (Top/Middle/Base) including informal power roles (gatekeepers, super-connectors, executive assistants where relevant). -- High-power stakeholder profiles covering goals/metrics, concerns/risks, preferred comms style, and political risks. -- Decision-making profile covering role identity, expected role behavior, likely information filters, in-group/out-group dynamics, and susceptibility to role pressure when relevant. -- A tailored engagement plan per high-power stakeholder (cadence/channel, format/owner, key message, quick win, fallback). -- A plan to inform/mobilize high-interest low-power stakeholders. -- Success signals/metrics and top 3 prioritized political pitfalls with mitigations. - -FORMAT -Return exactly this structure: - -Power-Interest Matrix -| Quadrant | Stakeholders | -| --- | --- | -| High Power / High Interest | [names] | -| High Power / Low Interest | [names] | -| Low Power / High Interest | [names] | -| Low Power / Low Interest | [names] | - -Influence Pyramid -- Top: [names + rationale] -- Middle: [names + rationale] -- Base: [names + rationale] - -High-Power Profiles -| Stakeholder | Goals & Success Metrics | Likely Concerns/Risks | Role Identity / Expected Behavior | Preferred Communication Style | Political Risks for Me | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -Decision-Making Influence Risks -- Role pressure: [who may decide from role expectation rather than evidence] -- In-group / out-group effects: [groups and likely interpretation gap] -- Authority or conformity risk: [risk and mitigation] -- Common-information risk: [shared info that may crowd out unique evidence] - -Engagement Plan -| Stakeholder | Cadence & Channel | Format | Owner | Key Message | Quick Win | Fallback | -| --- | --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | [row] | - -Advocacy Plan (High-Interest / Low-Power) -- [how to inform] -- [how to mobilize advocacy] - -Success Signals & Metrics -- [signal/metric] - -Risks & Mitigations -1. [pitfall + mitigation] -2. [pitfall + mitigation] -3. [pitfall + mitigation] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section/table is missing or materially incomplete. -- High-power stakeholders are not profiled and mapped to tailored engagement actions. -- Informal influence is ignored or unsupported. -- Role identity, in-group/out-group effects, or group decision influence risks are ignored when relevant. -- Top 3 political pitfalls and mitigations are missing, unprioritized, or generic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `power interest grid`, `stakeholder communication plan`, `raci`, `escalation path`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-stakeholder-power-interest-and-influence-map/references/pm-skills-main-merge.md b/.agents/skills/productize-stakeholder-power-interest-and-influence-map/references/pm-skills-main-merge.md deleted file mode 100644 index 40ac801c..00000000 --- a/.agents/skills/productize-stakeholder-power-interest-and-influence-map/references/pm-skills-main-merge.md +++ /dev/null @@ -1,59 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to add a power-interest grid, quadrant-specific communication plan, escalation path, and optional RACI matrix. - -## Routing Signals - -- power interest grid -- stakeholder communication plan -- raci -- escalation path - -## pm-execution/skills/stakeholder-map/SKILL.md - -## Stakeholder Mapping & Communication Plan - -Map stakeholders on a Power x Interest grid and create a tailored communication plan for each group. - -### Context - -You are helping build a stakeholder map for **$ARGUMENTS**. - -If the user provides files (org charts, project briefs, team rosters), read them first. If they describe the product or initiative, use that context to infer likely stakeholders. - -### Instructions - -1. **Identify stakeholders**: List all relevant individuals and groups -- executives, engineering leads, designers, marketing, sales, support, legal, finance, external partners, and end users. - -2. **Classify each stakeholder** on two dimensions: - - **Power** (High/Low): Their ability to influence decisions, resources, or outcomes - - **Interest** (High/Low): How much the project directly affects them or how engaged they are - -3. **Place stakeholders in the Power x Interest grid**: - - | | High Interest | Low Interest | - |---|---|---| - | **High Power** | **Manage Closely** -- Regular 1:1s, involve in decisions, seek their input early | **Keep Satisfied** -- Periodic updates, escalate only critical issues | - | **Low Power** | **Keep Informed** -- Regular status updates, invite to demos, gather feedback | **Monitor** -- Light-touch updates, available on request | - -4. **For each quadrant**, recommend: - - Communication frequency (daily, weekly, bi-weekly, monthly) - - Communication format (1:1, email, Slack, meeting, dashboard) - - Key messages and framing - - Potential risks if this stakeholder is neglected - -5. **Create a communication plan table**: - - | Stakeholder | Role | Power | Interest | Strategy | Frequency | Channel | Key Message | - |---|---|---|---|---|---|---|---| - -6. **Flag potential conflicts**: Identify stakeholders with competing interests and suggest alignment strategies. - -Think step by step. Save the stakeholder map as a markdown document. - ---- - -### Further Reading - -- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium) -- [Team Topologies: A Handbook to Set and Scale Product Teams](https://www.productcompass.pm/p/team-topologies-a-handbook-to-set) diff --git a/.agents/skills/productize-startup-canvas/SKILL.md b/.agents/skills/productize-startup-canvas/SKILL.md deleted file mode 100644 index 592c835a..00000000 --- a/.agents/skills/productize-startup-canvas/SKILL.md +++ /dev/null @@ -1,219 +0,0 @@ ---- -name: productize-startup-canvas -description: >- - Startup Canvas. Use when evaluating a startup concept or new product that needs product - strategy and business model logic in one founder-ready artifact. ---- - - - -# Startup Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `startup-canvas` -- **Lifecycle**: Think -- **Category**: Venture / 0-1 -- **Primary artifact**: Startup Canvas combining product strategy, business model, risks, and next validation steps - -Use when evaluating a startup concept or new product that needs product strategy and business model logic in one founder-ready artifact. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Startup Canvas combining product strategy, business model, risks, and next validation steps -- **Source method**: pm-skills-main/pm-product-strategy/skills/startup-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: startup-canvas -- **Description**: Generate a Startup Canvas for a new product. Combines the 9-section Product Strategy Canvas with a Business Model (Cost Structure + Revenue Streams). Designed specifically for startups and new products. -- **Triggers**: startup canvas, new product canvas, startup strategy, startup business model - -## Domain Context - -### Startup Canvas vs Business Model Canvas vs Lean Canvas - -Popular approaches like Business Model Canvas (Strategyzer) and Lean Canvas (Ash Maurya) mix strategy and business model into one artifact. The **Startup Canvas** (Pawe Huryn) separates them: 9 strategy sections from the Product Strategy Canvas + Cost Structure & Revenue Streams. - -**Why not Business Model Canvas?** -- No vision -- why should your team wake up every day? -- No Can't/Won't test -- what stops competitors from copying you? -- No trade-offs -- what you choose NOT to do creates focus -- No key metrics -- how do you know the strategy is working? -- Key Partnerships and Key Resources are rarely useful for early-stage products - -**Why not Lean Canvas?** -- Introduces redundancy: "Problem" overlaps with Market Segments (markets are defined by problems), "Solution" overlaps with Value Proposition (which by definition includes features) -- No vision, no trade-offs, no relative costs -- "Unfair Advantage" is too narrow -- the entire strategy should be hard to copy, not just one element -- Doesn't address the holistic fit of strategic choices reinforcing each other - -**When to use which:** -- **Business Model Canvas**: Established businesses, corporate strategy, investor materials -- **Lean Canvas**: Quick hypothesis testing when you just need speed -- **Startup Canvas**: New products where you need both strategic clarity AND a business model -- the recommended approach - -## Instructions - -You are a product strategist and startup advisor designing a Startup Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Startup Canvas that covers both the strategic choices and the business model for a new product. - -## Input Requirements -- Product or startup idea -- Target market and customer insights -- Competitive landscape -- Founder/team constraints and resources - -## Startup Canvas Template - -### Part 1: Product Strategy (9 Sections) - -**1. Vision** -- How can we inspire people? What are we aspiring to achieve? What values do we uphold? -- Start simple. Your vision will evolve alongside the strategy. - -**2. Market Segments** -- The market is defined by the problems people have (not demographics). -- Jobs to Be Done (JTBD), desired outcomes, constraints. -- What will be your first customer segment? Why this one first? - -**3. Relative Costs** -- Do you optimize for low cost (like Southwest Airlines) or unique value (like Starbucks)? -- Low costs don't necessarily mean low prices. - -**4. Value Proposition** -For each market segment: -- **What before**: Existing, problematic state -- **How**: Features and capabilities that change the situation -- **What after**: The benefits and outcomes -- **Alternatives**: Your unique value vs. competitors and substitutes (consider a Value Curve) - -**5. Trade-offs** -- What will you NOT do? Trade-offs create focus and amplify value. -- Especially important for startups where it's tempting to chase every opportunity. - -**6. Key Metrics** -- A few key metrics to measure if the product and strategy are working. -- North Star Metric and One Metric That Matters (OMTM) for this quarter. - -**7. Growth** -- Product-Led Growth or Sales-Led Growth? -- Preferred channels: Social Media, SEO, Influencers, Resellers? - -**8. Capabilities** -- What competencies and resources do you need to acquire? -- What do you build vs. partner for? - -**9. Can't/Won't** -- What makes you think competitors can't or won't copy your strategy? -- The entire strategy should be difficult to copy -- not just one element. -- Do all elements fit together and reinforce each other? - -### Part 2: Business Model - -**10. Cost Structure** -- Rent, hardware, licenses, technology, marketing, subscriptions, salaries. -- Which are recurring? How will they scale? - -**11. Revenue Streams** -- How much money from each channel? -- Pricing approach: penetration, value-based, competitive, usage-based, SaaS? -- Is the revenue model scalable? What are the biggest uncertainties? - -## Output Process -1. Define the vision and aspirational impact -2. Identify 2-3 target market segments with JTBD -3. Establish cost positioning (low cost vs premium) -4. Develop value propositions for each segment -5. List explicit trade-offs -6. Set North Star and quarterly OMTM -7. Outline growth strategy and channels -8. Document required capabilities -9. Explain defensibility (Can't/Won't test) -10. Estimate cost structure and revenue streams -11. Validate strategy coherence: do all elements reinforce each other? -12. Surface hypotheses that must be true for success -13. Suggest low-effort experiments to test key assumptions - -## Notes -- The Startup Canvas separates strategy from business model -- keep them distinct but connected -- Strategy should pass the Can't/Won't test: your competitors can't or won't copy the integrated set of choices -- After drafting the first version, identify and start testing hypotheses -- Mix and adapt approaches to suit your specific needs rather than following any canvas rigidly - ---- - -### Templates - -- [Startup Canvas (PPTX)](https://docs.google.com/presentation/d/1lA0SPflj5JT6jFV_jIDsqZJAYYperTFx/edit?usp=sharing&ouid=111307342557889008106&rtpof=true&sd=true) - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) -- [Product Strategy Canvas](https://www.productcompass.pm/p/product-strategy-canvas) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [Business Model Canvas Examples: Google Maps, Airbnb, Uber](https://www.productcompass.pm/p/business-model-canvas-examples) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/SKILL.md b/.agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/SKILL.md deleted file mode 100644 index 12245a84..00000000 --- a/.agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-structured-interview-notes-from-transcript-using-flexible -description: >- - Structured interview notes from transcript using flexible frameworks. Use when the user - needs a product workflow for user research related to structured interview notes from - transcript using flexible frameworks. Trigger terms: user-research, interviews, transcripts. ---- - - - -# Structured interview notes from transcript using flexible frameworks - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-interview-notes-from-transcript-using-flexible` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Structured interview notes from transcript using flexible frameworks**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- `{{INTERVIEW_TRANSCRIPT}}`: Source interview transcript. -- `{{NOTE_TAKING_MODE}}`: One of `Chronological`, `Topical`, `AEIOU Framework`, `Empathy Map`. - - -GOAL -Convert interview transcripts into concise, evidence-grounded structured notes using a selected note-taking framework. -Success metric: -- Notes are concise, atomic, and traceable to transcript content. -- Organization strictly follows the selected note-taking mode. -- Output uses the required tagged structure and one-column table format. - -CONSTRAINTS -- Use only provided inputs; if data is unclear, include explicit assumptions inside `` under an `Assumptions` subsection. -- Output only final notes wrapped in `` tags. -- Every note must: -- Capture exactly one idea. -- Be under 250 characters. -- Be grounded in transcript evidence. -- Use one-column markdown tables with clear category headers. -- Apply mode-specific organization: -- `Chronological`: single table ordered by transcript sequence. -- `Topical`: separate tables by major themes. -- `AEIOU Framework`: exactly five tables: Activities, Environments, Interactions, Objects, Users. -- `Empathy Map`: exactly eight tables: Thinks, Feels, Says, Does, Sees, Hears, Pains, Goals. -- If `{{NOTE_TAKING_MODE}}` is invalid or missing, default to `Topical` and record this in `Assumptions`. - -FORMAT -Return exactly this structure: - - -[Mode label] - -[Category Header] -| Note | -| --- | -| [One atomic note under 250 chars] | -| [One atomic note under 250 chars] | - -[Repeat tables according to selected mode] - -Assumptions (only if needed) -| Note | -| --- | -| [Explicit assumption due to missing/ambiguous data] | - - -FAILURE -- `` wrapper is missing or malformed. -- Tables are missing, not one-column, unlabeled, or not aligned with selected/default mode. -- Required mode categories are missing (AEIOU or Empathy Map). -- Notes exceed 250 characters, combine multiple ideas, or are not transcript-grounded. -- Output includes analysis/explanations outside structured notes. -- Assumptions are needed but not explicitly listed. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `summarize interview`, `interview notes`, `satisfaction signals`, `action items`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/references/pm-skills-main-merge.md b/.agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/references/pm-skills-main-merge.md deleted file mode 100644 index 5b72dc8c..00000000 --- a/.agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/references/pm-skills-main-merge.md +++ /dev/null @@ -1,61 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make interview transcript summaries include JTBD, satisfaction signals, quotes, and action items. - -## Routing Signals - -- summarize interview -- interview notes -- satisfaction signals -- action items - -## pm-product-discovery/skills/summarize-interview/SKILL.md - -## Summarize Customer Interview - -Transform an interview transcript into a structured summary focused on Jobs to Be Done, satisfaction, and action items. - -### Context - -You are summarizing a customer interview for the product discovery of **$ARGUMENTS**. - -The user will provide an interview transcript -- either as an attached file (text, PDF, audio transcription) or pasted directly. Read any attached files first. - -### Instructions - -1. **Read the full transcript** carefully before summarizing. - -2. **Fill in the summary template** below. Use "-" if information is unavailable. Replace numeric values with qualitative descriptions if needed (e.g., "not satisfied"). - -3. **Use clear, simple language** -- a primary school graduate should be able to understand the summary. - -### Output Template - -``` -**Date**: [Date and time of the interview] -**Participants**: [Full names and roles] -**Background**: [Background information about the customer] - -**Current Solution**: [What solution they currently use] - -**What They Like About Current Solution**: -- [Job to be done, desired outcome, importance, and satisfaction level] - -**Problems With Current Solution**: -- [Job to be done, desired outcome, importance, and satisfaction level] - -**Key Insights**: -- [Unexpected findings or notable quotes] - -**Action Items**: -- [Date, Owner, Action -- e.g., "2025-01-15, Pawe Huryn, Follow up with customer about pricing"] -``` - -Save the summary as a markdown document in the user's workspace. - ---- - -### Further Reading - -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) diff --git a/.agents/skills/productize-test-scenarios/SKILL.md b/.agents/skills/productize-test-scenarios/SKILL.md deleted file mode 100644 index e2dc656d..00000000 --- a/.agents/skills/productize-test-scenarios/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: productize-test-scenarios -description: >- - Test Scenarios. Use when creating test scenarios from user stories, feature specs, PRDs, - acceptance criteria, or agent-ready implementation plans. ---- - - - -# Test Scenarios - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `test-scenarios` -- **Lifecycle**: Build With AI -- **Category**: Delivery -- **Primary artifact**: QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix - -Use when creating test scenarios from user stories, feature specs, PRDs, acceptance criteria, or agent-ready implementation plans. - -## Productize Contract - -- **Primary lifecycle**: Build With AI -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix -- **Source method**: pm-skills-main/pm-execution/skills/test-scenarios/SKILL.md - -## Method - -Create comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step test actions, and expected outcomes. - -**Use when:** Writing QA test cases, creating test plans, defining acceptance test scenarios, or validating user story implementations. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$USER_STORY`: The user story to test (title and acceptance criteria) -- `$CONTEXT`: Additional testing context or constraints - -## Step-by-Step Process - -1. **Review the user story** and acceptance criteria -2. **Define test objectives** - What specific behavior to validate -3. **Establish starting conditions** - System state, data setup, configurations -4. **Identify user roles** - Who performs the test actions -5. **Create test steps** - Break down interactions step-by-step -6. **Define expected outcomes** - Observable results after each step -7. **Consider edge cases** - Invalid inputs, boundary conditions -8. **Output detailed test scenarios** - Ready for QA execution - -## Scenario Template - -**Test Scenario:** [Clear scenario name] - -**Test Objective:** [What this test validates] - -**Starting Conditions:** -- [System state required] -- [Data or configuration needed] -- [User setup or permissions] - -**User Role:** [Who performs the test] - -**Test Steps:** -1. [First action and its expected result] -2. [Second action and observable outcome] -3. [Third action and system behavior] -4. [Completion action and final state] - -**Expected Outcomes:** -- [Observable result 1] -- [Observable result 2] -- [Observable result 3] - -## Example Test Scenario - -**Test Scenario:** View Recently Viewed Products on Product Page - -**Test Objective:** Verify that the 'Recently viewed' section displays correctly and excludes the current product. - -**Starting Conditions:** -- User is logged in or has browser history enabled -- User has viewed at least 2 products in the current session -- User is now on a product page different from previously viewed items - -**User Role:** Online Shopper - -**Test Steps:** -1. Navigate to any product page -> Section should appear at bottom with previously viewed items -2. Scroll to bottom of page -> "Recently viewed" section is visible with product cards -3. Verify product thumbnails -> Images, titles, and prices are displayed correctly -4. Check current product -> Current product is NOT in the recently viewed list -5. Click on a product card -> User navigates to the corresponding product page - -**Expected Outcomes:** -- Recently viewed section appears only after viewing at least 1 prior product -- Section displays 4-8 product cards with complete information -- Current product is excluded from the list -- Each card shows "Viewed X minutes/hours ago" timestamp -- Clicking cards navigates to correct product pages -- Performance: Section loads within 2 seconds - -## Output Deliverables - -- Comprehensive test scenarios for each acceptance criterion -- Clear test objectives aligned with user story intent -- Detailed step-by-step test actions -- Observable expected outcomes after each step -- Edge case and error scenario coverage -- Ready for QA team execution and documentation - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md b/.agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md deleted file mode 100644 index 5476209b..00000000 --- a/.agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -name: productize-user-stories-with-gherkin-acceptance-criteria-from-requirements -description: >- - User stories with Gherkin acceptance criteria from requirements. Use when the user needs a - product workflow for business analysis related to user stories with gherkin acceptance - criteria from requirements. Trigger terms: pm, user-stories, gherkin, requirements, - business-analysis. ---- - - - -# User stories with Gherkin acceptance criteria from requirements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `user-stories-with-gherkin-acceptance-criteria-from-requirements` -- **Lifecycle**: Design -- **Category**: Delivery -- **Primary artifact**: User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **User stories with Gherkin acceptance criteria from requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Generate INVEST-compliant, atomic user stories with Gherkin acceptance criteria from provided requirements context. -Success metric: -- Produces one or more atomic user stories aligned to persona goals and constraints. -- Each story includes deterministic happy-path and edge/negative Gherkin scenarios. -- Includes traceability from requirements to stories and acceptance criteria. -- Follows the required markdown output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required steps: - 1. Decompose requirements into distinct atomic outcomes. - 2. Draft one story per outcome. - 3. Add Gherkin acceptance criteria with one `When` and one `Then` in happy path. - 4. Add at least one edge/negative scenario per story. - 5. Complete notes and traceability mapping. -- Stories must be INVEST-compliant and persona-aligned. -- If a story would require multiple primary outcomes, split it or mark `SPLIT SUGGESTED`. -- Keep language testable and implementation-neutral (unless a technical constraint is explicitly required). -- Use `[TBD]` for critical missing info and surface it under Open Questions. - -FORMAT -Return exactly this structure: - -```md -Backlog Context -[Backlog Header Template fields filled] - -User Story [ID-###]: -[Use Case + Gherkin happy-path scenario + Gherkin edge/negative scenario] -Notes -[Non-Functional, Instrumentation, Dependencies, Out of Scope, Open Questions] - -[Repeat story blocks for each atomic outcome] - -Traceability Table -[Requirement ID | Requirement Summary | Story ID(s) | AC Coverage Notes] - -Validation Checklist -[All required checklist items] -``` - -FAILURE -- Required markdown structure is missing or malformed. -- Stories are non-atomic, non-INVEST, or not mapped to clear outcomes. -- Happy-path scenario contains more than one `When` or more than one `Then` without `SPLIT SUGGESTED`. -- Edge/negative scenario is missing for any story. -- Traceability table or validation checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `3 cs`, `invest`, `user stories`, `conversation confirmation`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/references/pm-skills-main-merge.md b/.agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/references/pm-skills-main-merge.md deleted file mode 100644 index 18b92c9c..00000000 --- a/.agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/references/pm-skills-main-merge.md +++ /dev/null @@ -1,81 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to improve story quality with 3 Cs, INVEST checks, conversation notes, design links, and acceptance criteria. - -## Routing Signals - -- 3 cs -- invest -- user stories -- conversation confirmation - -## pm-execution/skills/user-stories/SKILL.md - -Create user stories following the 3 C's (Card, Conversation, Confirmation) and INVEST criteria. Generates stories with descriptions, design links, and acceptance criteria. - -**Use when:** Writing user stories, breaking down features into stories, creating backlog items, or defining acceptance criteria. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$FEATURE`: The new feature to break into stories -- `$DESIGN`: Link to design files (Figma, Miro, etc.) -- `$ASSUMPTIONS`: Key assumptions or context - -## Step-by-Step Process - -1. **Analyze the feature** based on provided design and context -2. **Identify user roles** and distinct user journeys -3. **Apply 3 C's framework:** - - Card: Simple title and one-liner - - Conversation: Detailed discussion of intent - - Confirmation: Clear acceptance criteria -4. **Respect INVEST criteria:** Independent, Negotiable, Valuable, Estimable, Small, Testable -5. **Use plain language** a primary school graduate can understand -6. **Link to design files** for visual reference -7. **Output user stories** in structured format - -## Story Template - -**Title:** [Feature name] - -**Description:** As a [user role], I want to [action], so that [benefit]. - -**Design:** [Link to design files] - -**Acceptance Criteria:** -1. [Clear, testable criterion] -2. [Observable behavior] -3. [System validates correctly] -4. [Edge case handling] -5. [Performance or accessibility consideration] -6. [Integration point] - -## Example User Story - -**Title:** Recently Viewed Section - -**Description:** As an Online Shopper, I want to see a 'Recently viewed' section on the product page to easily revisit items I considered. - -**Design:** [Figma link] - -**Acceptance Criteria:** -1. The 'Recently viewed' section is displayed at the bottom of the product page for every user who has previously viewed at least 1 product. -2. It is not displayed for users visiting the first product page of their session. -3. The current product itself is excluded from the displayed items. -4. The section showcases product cards or thumbnails with images, titles, and prices. -5. Each product card indicates when it was viewed (e.g., 'Viewed 5 minutes ago'). -6. Clicking on a product card leads the user to the corresponding product page. - -## Output Deliverables - -- Complete set of user stories for the feature -- Each story includes title, description, design link, and 4-6 acceptance criteria -- Stories are independent and can be developed in any order -- Stories are sized for one sprint cycle -- Stories reference related design documentation - ---- - -### Further Reading - -- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories) diff --git a/.agents/skills/productize-write-query/SKILL.md b/.agents/skills/productize-write-query/SKILL.md deleted file mode 100644 index 85189156..00000000 --- a/.agents/skills/productize-write-query/SKILL.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -name: productize-write-query -description: >- - Write optimized SQL for a specific dialect with best practices. Use when translating a - natural language data need into SQL, building a multi-CTE query with joins and aggregations, - optimizing a large partitioned-table query, or getting Snowflake, BigQuery, Postgres, or - other dialect syntax. ---- - - - -# Write Query - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `write-query` -- **Lifecycle**: Plan -- **Category**: Analytics -- **Primary artifact**: Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Write a SQL query from a natural-language description, optimized for the user's SQL dialect and use case. - -## Argument Hint - -`` - -## Usage - -```text -/write-query -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `sql generator`, `bigquery`, `postgres`, `mysql`, `schema diagram`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Understand the Request - -Parse the user's description to identify: -- Output columns. -- Filters: time ranges, segments, statuses, exclusions. -- Aggregations: counts, sums, averages, rates, distincts. -- Joins and required entities. -- Ordering. -- Limits, top-N, or sample requirements. -- Expected grain: one row per what. - -If the request is ambiguous, ask only for the missing detail that changes query correctness. - -### 2. Determine SQL Dialect - -If not known, ask which dialect they use: -- PostgreSQL, including Aurora, RDS, Supabase, Neon. -- Snowflake. -- BigQuery. -- Redshift. -- Databricks SQL. -- MySQL. -- SQL Server. -- DuckDB. -- SQLite. -- Other. - -Use `sql-queries` for dialect-specific syntax, date functions, semi-structured data, performance notes, and debugging. - -### 3. Discover Schema - -If a warehouse or schema tool is connected: -1. Search for relevant tables. -2. Inspect column names, types, and relationships. -3. Check partition, clustering, sort, or distribution keys. -4. Look for existing views or materialized views. - -If no warehouse is connected: -- Ask for table names, schema, or sample rows. -- If the schema is unknown, provide a query template with clearly marked placeholders. - -### 4. Write the Query - -Structure: -- Use CTEs for multi-step logic. -- Use one CTE per logical transformation or source. -- Name CTEs descriptively. -- Keep the final SELECT easy to scan. - -Performance: -- Avoid `SELECT *` in production queries. -- Filter early, especially on dates and partitions. -- Use partition filters for BigQuery/Databricks and clustering/sort-aware filters for Snowflake/Redshift. -- Use appropriate join types. -- Avoid correlated subqueries when joins or windows are clearer. -- Watch for many-to-many joins and potential row multiplication. -- Prefer approximate distinct functions only when accuracy tradeoffs are acceptable and stated. - -Readability: -- Add comments for non-obvious business logic. -- Use consistent formatting and indentation. -- Use meaningful table aliases. -- Put major clauses on their own lines. - -Correctness: -- Protect rate denominators with `NULLIF` or dialect-safe division. -- Define timezones and date boundaries. -- Deduplicate before aggregation when needed. -- Keep metric definitions explicit. - -### 5. Present the Query - -Provide: -1. Complete SQL code block. -2. Short explanation of each CTE or major section. -3. Performance notes and likely bottlenecks. -4. Modification suggestions for date range, granularity, dimensions, or filters. -5. Validation checks the user can run. - -### 6. Offer Execution or Review - -If a warehouse is connected, offer to run the query and inspect results. If the user will run it themselves, make the query copy-paste ready. - -## Output Template - -````markdown -## Query - -```sql --- SQL here -``` - -## How It Works -- `[cte_name]`: ... - -## Performance Notes -- ... - -## Validation Checks -- Row count before and after joins. -- Date range coverage. -- Duplicate key checks. -- Aggregate reconciliation. - -## Common Modifications -- To change time range: ... -- To group by another dimension: ... -```` - -## Examples - -- Count orders by status for the last 30 days. -- Cohort retention by signup month with activity at 1, 3, 6, and 12 months. -- Top 100 users by event count in the last 7 days from a large partitioned events table. - -## Rules - -- Do not invent exact table or column names when schema is unknown; use placeholders or ask for schema. -- If using assumptions, state them next to the query. -- For recurring queries, parameterize date ranges when the dialect supports it. -- For high-stakes analysis, recommend `validate-data` after results are produced. diff --git a/.agents/skills/productize-write-query/references/pm-skills-main-merge.md b/.agents/skills/productize-write-query/references/pm-skills-main-merge.md deleted file mode 100644 index 8cc6198d..00000000 --- a/.agents/skills/productize-write-query/references/pm-skills-main-merge.md +++ /dev/null @@ -1,94 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to strengthen SQL generation across dialects and schema interpretation from product analytics questions. - -## Routing Signals - -- sql generator -- bigquery -- postgres -- mysql -- schema diagram - -## pm-data-analytics/skills/sql-queries/SKILL.md - -## Purpose -Transform natural language requirements into optimized SQL queries across multiple database platforms. This skill helps product managers, analysts, and engineers generate accurate queries without manual syntax work. - -## How It Works - -### Step 1: Understand Your Database Schema -- If you provide a schema file (SQL, documentation, or diagram description), I will read and analyze it -- Extract table names, column definitions, data types, and relationships -- Identify primary keys, foreign keys, and indexing strategies - -### Step 2: Process Your Request -- Clarify the exact data you need to retrieve or analyze -- Confirm the SQL dialect (BigQuery, PostgreSQL, MySQL, Snowflake, etc.) -- Ask for any additional requirements (filters, aggregations, sorting) - -### Step 3: Generate Optimized Query -- Write efficient SQL that leverages your database structure -- Include comments explaining complex logic -- Add performance considerations for large datasets -- Provide alternative approaches if applicable - -### Step 4: Explain and Test -- Explain the query logic in plain English -- Suggest how to test or validate results -- Offer tips for performance optimization -- If you want, generate a test script or sample data - -## Usage Examples - -**Example 1: Query from Schema File** -``` -Upload your database_schema.sql file and say: -"Generate a query to find users who signed up in the last 30 days -and had at least 5 active sessions" -``` - -**Example 2: Query from Diagram Description** -``` -"Here's my database: Users table (id, email, created_at), Sessions table -(id, user_id, timestamp, duration). Generate a query for average session -duration per user in January 2026." -``` - -**Example 3: Complex Analysis Query** -``` -"Create a BigQuery query to analyze our revenue by region and customer tier, -including year-over-year growth rates." -``` - -## Key Capabilities - -- **Multi-Dialect Support**: Works with BigQuery, PostgreSQL, MySQL, Snowflake, SQL Server -- **File Reading**: Reads schema files, SQL dumps, and data documentation -- **Query Optimization**: Suggests indexes, partitioning, and performance improvements -- **Explanation**: Breaks down queries for learning and documentation -- **Testing**: Can generate test queries and sample data scripts -- **Script Execution**: Create executable SQL scripts for your database - -## Tips for Best Results - -1. **Provide context**: Share your database schema or structure -2. **Be specific**: Clearly describe what data you need and any filters -3. **Mention database**: Specify which SQL dialect you're using -4. **Include constraints**: Mention data volume, time ranges, and performance needs -5. **Request format**: Ask for the query result format if you need specific output - -## Output Format - -You'll receive: -- **SQL Query**: Production-ready SQL code with comments -- **Explanation**: What the query does and how it works -- **Performance Notes**: Optimization tips and considerations -- **Test Script** (if requested): Sample data and validation queries - ---- - -### Further Reading - -- [The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs](https://www.productcompass.pm/p/the-product-analytics-playbook-aarrr) -- [How to Become a Technology-Literate PM](https://www.productcompass.pm/p/how-to-become-a-technology-literate) diff --git a/.agents/skills/productize-write-spec/SKILL.md b/.agents/skills/productize-write-spec/SKILL.md deleted file mode 100644 index fee66644..00000000 --- a/.agents/skills/productize-write-spec/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: productize-write-spec -description: >- - Write a feature spec or PRD from a problem statement or feature idea. Use when turning a - vague idea into a structured document, scoping goals and non-goals, defining success metrics - and acceptance criteria, or breaking a big ask into phases. ---- - - - -# Write Spec - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `write-spec` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Feature spec or PRD with scope, success metrics, and acceptance criteria - -Write a feature specification or product requirements document. - -## Argument Hint - -`` - -## Usage - -```text -/write-spec $ARGUMENTS -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `create prd`, `8-section prd`, `feature spec`, `release planning`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Understand the Feature - -Accept a feature name, problem statement, user request, or vague idea. - -Ask conversationally for the most important missing context: -- User problem and affected segment. -- Success metrics. -- Constraints, dependencies, deadlines. -- Prior attempts or related solutions. - -### 2. Pull Context - -If connected, search project tracker, docs, research, design files, and meeting notes for related work, requirements, mockups, decisions, and dependencies. - -If tools are not connected, proceed from user-provided context and state assumptions. - -### 3. Generate PRD - -Include: -- **Problem Statement**: 2-3 sentences with user, pain, frequency, and impact. -- **Goals**: 3-5 measurable outcomes. -- **Non-Goals**: 3-5 out-of-scope items with rationale. -- **User Stories**: "As a [user], I want [capability], so that [benefit]." -- **Requirements**: P0, P1, P2 with acceptance criteria. -- **Success Metrics**: leading and lagging indicators with targets and measurement method. -- **Open Questions**: tagged by owner and blocking status. -- **Timeline Considerations**: hard deadlines, dependencies, phasing. - -### 4. Acceptance Criteria - -Use Given/When/Then or checklist format. Cover: -- Happy path. -- Error states. -- Empty states. -- Boundary conditions. -- Negative cases. - -### 5. Scope Rules - -- Be opinionated about v1 scope. -- If everything is P0, challenge it. -- Require scope addition to come with scope removal or timeline extension. -- Separate v1 from future considerations. -- Keep requirements behavior-focused, not implementation-prescriptive unless necessary. - -## Output Rules - -Use clear markdown headers and tables where helpful. Keep the spec skimmable. Open questions must be genuinely unresolved. diff --git a/.agents/skills/productize-write-spec/references/pm-skills-main-merge.md b/.agents/skills/productize-write-spec/references/pm-skills-main-merge.md deleted file mode 100644 index fbb9df1e..00000000 --- a/.agents/skills/productize-write-spec/references/pm-skills-main-merge.md +++ /dev/null @@ -1,92 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to sharpen PRD structure around problem, objectives, segments, value proposition, solution, scope, and release planning. - -## Routing Signals - -- create prd -- 8-section prd -- feature spec -- release planning - -## pm-execution/skills/create-prd/SKILL.md - -## Purpose - -You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development. - -## Context - -A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders. - -## Instructions - -1. **Gather Information**: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights. - -2. **Think Step by Step**: Before writing, analyze: - - What problem are we solving? - - Who are we solving it for? - - How will we measure success? - - What are our constraints and assumptions? - -3. **Apply the PRD Template**: Create a document with these 8 sections: - - **1. Summary** (2-3 sentences) - - What is this document about? - - **2. Contacts** - - Name, role, and comment for key stakeholders - - **3. Background** - - Context: What is this initiative about? - - Why now? Has something changed? - - Is this something that just recently became possible? - - **4. Objective** - - What's the objective? Why does it matter? - - How will it benefit the company and customers? - - How does it align with vision and strategy? - - Key Results: How will you measure success? (Use SMART OKR format) - - **5. Market Segment(s)** - - For whom are we building this? - - What constraints exist? - - Note: Markets are defined by people's problems/jobs, not demographics - - **6. Value Proposition(s)** - - What customer jobs/needs are we addressing? - - What will customers gain? - - Which pains will they avoid? - - Which problems do we solve better than competitors? - - Consider the Value Curve framework - - **7. Solution** - - 7.1 UX/Prototypes (wireframes, user flows) - - 7.2 Key Features (detailed feature descriptions) - - 7.3 Technology (optional, only if relevant) - - 7.4 Assumptions (what we believe but haven't proven) - - **8. Release** - - How long could it take? - - What goes in the first version vs. future versions? - - Avoid exact dates; use relative timeframes - -4. **Use Accessible Language**: Write for a primary school graduate. Avoid jargon. Use clear, short sentences. - -5. **Structure Output**: Present the PRD as a well-formatted markdown document with clear headings and sections. - -6. **Save the Output**: If the PRD is substantial (which it will be), save it as a markdown document in the format: `PRD-[product-name].md` - -## Notes - -- Be specific and data-driven where possible -- Link each section back to the overall strategy -- Flag assumptions clearly so the team can validate them -- Keep the document concise but complete - ---- - -### Further Reading - -- [How to Write a Product Requirements Document? The Best PRD Template.](https://www.productcompass.pm/p/prd-template) -- [A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)](https://www.productcompass.pm/p/ai-prd-template) diff --git a/.agents/skills/productize-wwas/SKILL.md b/.agents/skills/productize-wwas/SKILL.md deleted file mode 100644 index fd4c1ab3..00000000 --- a/.agents/skills/productize-wwas/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-wwas -description: >- - Why-What-Acceptance. Use when writing backlog items in Why-What-Acceptance format, breaking - features into independent valuable work, or adding strategic context to delivery items. ---- - - - -# Why-What-Acceptance - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `wwas` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Why-What-Acceptance backlog items with strategic context and acceptance criteria - -Use when writing backlog items in Why-What-Acceptance format, breaking features into independent valuable work, or adding strategic context to delivery items. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: Build With AI -- **Primary artifact**: Why-What-Acceptance backlog items with strategic context and acceptance criteria -- **Source method**: pm-skills-main/pm-execution/skills/wwas/SKILL.md - -## Method - -Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context. - -**Use when:** Writing backlog items, creating product increments, breaking features into work items, or communicating strategic intent to teams. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$FEATURE`: The new feature or capability -- `$DESIGN`: Link to design files (Figma, Miro, etc.) -- `$ASSUMPTIONS`: Key assumptions and strategic context - -## Step-by-Step Process - -1. **Define the strategic Why** - Connect work to business and team objectives -2. **Describe the What** - Keep descriptions concise, reference designs -3. **Write Acceptance Criteria** - High-level, not detailed specifications -4. **Ensure independence** - Items can be developed in any order -5. **Keep items negotiable** - Invite team conversation, not constraints -6. **Make items valuable** - Each delivers measurable user or business value -7. **Ensure testability** - Outcomes are observable and verifiable -8. **Size appropriately** - Small enough for one sprint estimate - -## Item Template - -**Title:** [What will be delivered] - -**Why:** [1-2 sentences connecting to strategic context and team objectives] - -**What:** [Short description and design link. 1-2 paragraphs maximum. A reminder of discussion, not detailed specification.] - -**Acceptance Criteria:** -- [Observable outcome 1] -- [Observable outcome 2] -- [Observable outcome 3] -- [Observable outcome 4] - -## Example WWA Item - -**Title:** Implement Real-Time Spending Tracker - -**Why:** Users need immediate feedback on spending to make conscious budget decisions. This directly supports our goal to improve financial awareness and reduce overspending. - -**What:** Add a real-time spending tracker that updates as users log expenses. The tracker displays their current week's spending against their set budget. Designs available in [Figma link]. This is a reminder of our discussions - detailed specifications will emerge during development conversations with the team. - -**Acceptance Criteria:** -- Spending totals update within 2 seconds of logging an expense -- Budget progress is visually indicated with a progress bar -- Users can see remaining budget amount at a glance -- System handles multiple expense categories correctly - -## Output Deliverables - -- Complete set of backlog items for the feature -- Each item includes Why, What, and Acceptance Criteria sections -- Items are independent and deliverable in any order -- Items are sized for estimation and completion in one sprint -- Strategic context is clear for team decision-making -- Design references are included for implementation guidance - ---- - -### Further Reading - -- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json deleted file mode 100644 index 10f353bd..00000000 --- a/.claude-plugin/marketplace.json +++ /dev/null @@ -1,636 +0,0 @@ -{ - "name": "productize-agent-skills", - "owner": { - "name": "Productize AI" - }, - "metadata": { - "description": "Agent skills for product leaders and AI builders.", - "version": "1.1.2" - }, - "plugins": [ - { - "name": "productize-discovery", - "description": "Product learning, qualitative research, JTBD, assumptions, opportunity mapping, ideation, personas, and synthesis.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/actionable-customer-interview-guides-from-research-topics", - "./.claude/skills/actionable-job-stories-from-interview-transcripts", - "./.claude/skills/actionable-product-improvements-from-survey-responses", - "./.claude/skills/actionable-research-briefs-from-problem-statements-and", - "./.claude/skills/actionable-user-profiles-with-tasks-and-constraints-from", - "./.claude/skills/actionable-user-research-decisions-from-project-insights", - "./.claude/skills/aging-research-insight-validation-before-reusing", - "./.claude/skills/app-aha-moment-identification-from-user-data-and-app", - "./.claude/skills/brainstorm", - "./.claude/skills/clustered-jtbd-forces-from-interview-data", - "./.claude/skills/comprehensive-use-cases-from-user-input-for-product-strategy", - "./.claude/skills/creative-solution-generation-from-de-bono-s-lateral-thinking", - "./.claude/skills/creative-solution-generation-from-metaphorical-thinking", - "./.claude/skills/customer-insights-extraction-from-interview-transcript-using", - "./.claude/skills/data-driven-research-plans-from-leadership-intuition", - "./.claude/skills/easy-signal-identification-from-product-assumption", - "./.claude/skills/effective-customer-interview-guides-for-any-topic", - "./.claude/skills/empathy-maps", - "./.claude/skills/feature-impact-models-from-kpis-and-assumptions", - "./.claude/skills/fragmented-user-research-synthesis-into-coherent-insights", - "./.claude/skills/ideal-customer-profile-icp-representative-for-x-product", - "./.claude/skills/innovative-idea-generation-from-project-parameters-and", - "./.claude/skills/innovative-idea-generation-from-structured-brainstorming", - "./.claude/skills/innovative-product-ideas-from-structured-brainstorming", - "./.claude/skills/interactive-intake-for-ost-inputs", - "./.claude/skills/market-requirements-from-strategic-market-inputs", - "./.claude/skills/now-next-later-vision-roadmap-from-interview-synthesis", - "./.claude/skills/offbeat-question-generation-from-any-topic", - "./.claude/skills/opportunity-solution-tree-from-input", - "./.claude/skills/post-launch-feedback-into-v2-improvements-synthesis", - "./.claude/skills/post-launch-feedback-loop", - "./.claude/skills/problem-framing-before-jumping-to-solutions", - "./.claude/skills/problem-statement-framing-from-conversation-transcript", - "./.claude/skills/product-assumptions-from-core-strategy-inputs", - "./.claude/skills/product-brainstorming", - "./.claude/skills/product-decision-analysis-from-anthropological-research", - "./.claude/skills/proto-persona-profiles-from-user-research-and-market-data", - "./.claude/skills/raw-interview-transcript-cleanup", - "./.claude/skills/realistic-jtbd-interview-transcripts", - "./.claude/skills/research-into-durable-competitive-moats", - "./.claude/skills/risky-assumption-prioritization-for-rapid-validation", - "./.claude/skills/robust-experiment-design-from-goals-and-systems", - "./.claude/skills/structured-interview-notes-from-transcript-using-flexible", - "./.claude/skills/structured-product-hypotheses-from-product-problems", - "./.claude/skills/support-tickets-as-actionable-product-improvements", - "./.claude/skills/synthesize-research", - "./.claude/skills/target-opportunity-selection-from-ost" - ] - }, - { - "name": "productize-strategy", - "description": "Positioning, market structure, moats, prioritization logic, roadmaps, OKRs, competitive choices, and strategic decisions.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/adaptive-planning-from-scenarios-to-strategic-actions", - "./.claude/skills/ai-product-evaluation-from-recommendation-canvas-framework", - "./.claude/skills/business-strategy-creation-from-expert-strategic-thinking", - "./.claude/skills/competitive-advantage-diagnostics-and-moat-strategy", - "./.claude/skills/competitive-parity-and-strategic-differentiation", - "./.claude/skills/complex-problem-structuring-into-actionable-recommendations", - "./.claude/skills/decision-reversibility-classification-from-first-principles", - "./.claude/skills/framework-application-to-product-challenges-from-user-input", - "./.claude/skills/future-product-opportunities-from-market-inflection-points", - "./.claude/skills/limit-based-product-strategy-from-problem-to-execution-plan", - "./.claude/skills/mece-analysis-and-logical-tree-from-list-items", - "./.claude/skills/netmba-competitor-analysis", - "./.claude/skills/okr-planning-from-vision-statements", - "./.claude/skills/pmf-review", - "./.claude/skills/product-simplification-via-via-negativa-analysis", - "./.claude/skills/root-cause-and-consequence-analysis-from-a-question", - "./.claude/skills/solution-anti-patterns-from-customer-problem-analysis", - "./.claude/skills/strategic-crux-diagnosis-and-strategy-design", - "./.claude/skills/strategic-moves-from-swot-pairings", - "./.claude/skills/strategy-kernel-extraction-from-context", - "./.claude/skills/strategy-to-execution-bridge-for-ux-decisions", - "./.claude/skills/structured-product-strategy-from-product-context", - "./.claude/skills/task-specific-product-strategy-design", - "./.claude/skills/thesis-review", - "./.claude/skills/value-chain-mapping-from-end-user-needs-to-core-value" - ] - }, - { - "name": "productize-decision-making", - "description": "Strategic decision quality, bias and heuristic review, visual decision support, group decision process, role identity, and decision records.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/decision-making-with-the-gut-check-protocol", - "./.claude/skills/group-decision-making-quality-review", - "./.claude/skills/innovation-decision-making-heuristics", - "./.claude/skills/meeting-outcome-planning-and-stakeholder-alignment", - "./.claude/skills/pre-mortem", - "./.claude/skills/role-identity-decision-making-map", - "./.claude/skills/stakeholder-decision-making-using-toc-thinking-process", - "./.claude/skills/stakeholder-power-interest-and-influence-map", - "./.claude/skills/strategic-decision-making-quality-review", - "./.claude/skills/structured-decision-journals-from-decisions-and-context", - "./.claude/skills/visual-decision-making-review" - ] - }, - { - "name": "productize-growth", - "description": "Activation, retention, expansion, PLG, PQLs, growth loops, lifecycle triggers, GTM motions, and sustainable growth experiments.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/aarrr-growth-diagnostics", - "./.claude/skills/churn-reduction-from-customer-data-and-exit-survey-analysis", - "./.claude/skills/grow", - "./.claude/skills/growth-loops", - "./.claude/skills/growth-project-generation-with-pioneer-migrator-settler", - "./.claude/skills/growth-strategy-synthesis-from-user-inputs", - "./.claude/skills/gtm-motions", - "./.claude/skills/gtm-strategy", - "./.claude/skills/low-frequency-to-power-user-transition-strategy", - "./.claude/skills/onboarding-flow-optimization-from-product-data-to-user-success", - "./.claude/skills/plg-growth-playbook", - "./.claude/skills/product-market-fit-cycle" - ] - }, - { - "name": "productize-analytics", - "description": "Product metrics, dashboards, SQL, cohorts, experiments, data quality, statistical analysis, and instrumentation.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/ab-test-analysis", - "./.claude/skills/analyze", - "./.claude/skills/build-dashboard", - "./.claude/skills/cohort-analysis", - "./.claude/skills/create-viz", - "./.claude/skills/customer-journey-map-based-on-user-behavior-data", - "./.claude/skills/data-context-extractor", - "./.claude/skills/data-visualization", - "./.claude/skills/event-tracking-schemas-from-ui-and-metrics-requirements", - "./.claude/skills/explore-data", - "./.claude/skills/feature-results-analysis-from-draft-to-final-report", - "./.claude/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition", - "./.claude/skills/metrics-review", - "./.claude/skills/north-star-metric", - "./.claude/skills/product-feature-impact-sizing-from-metrics-and-usage-data", - "./.claude/skills/sql-queries", - "./.claude/skills/sql-query-from-requirements-and-data-tables", - "./.claude/skills/statistical-analysis", - "./.claude/skills/success-metrics-for-design-decisions", - "./.claude/skills/trade-off-analysis-from-feature-priority-and-effort-data", - "./.claude/skills/validate-data", - "./.claude/skills/write-query" - ] - }, - { - "name": "productize-finance", - "description": "Valuation, DCF, NPV, IRR, WACC, CAPM, capital structure, startup financing, cap tables, dilution, deal pricing, and market context.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/capital-structure-financing", - "./.claude/skills/finance-modeling-kernel", - "./.claude/skills/financial-markets-context", - "./.claude/skills/managerial-finance-dcf", - "./.claude/skills/risk-return-cost-of-capital", - "./.claude/skills/valuation-and-deal-pricing", - "./.claude/skills/venture-capital-deal-modeling" - ] - }, - { - "name": "productize-delivery", - "description": "PRDs, requirements, backlog items, sprint plans, QA scenarios, launch readiness, release notes, and execution planning.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/analyze-feature-requests", - "./.claude/skills/bug-prioritization-against-work-in-progress", - "./.claude/skills/critical-flaws-in-product-requirements-tough-and-unreasonable", - "./.claude/skills/detailed-project-plans-from-project-briefs", - "./.claude/skills/docs", - "./.claude/skills/dogfood", - "./.claude/skills/nps-feedback-for-prioritized-customer-experience-initiatives", - "./.claude/skills/outcome-roadmap", - "./.claude/skills/prds-from-industry-and-feature-specifications", - "./.claude/skills/prds-from-product-information-and-assumptions", - "./.claude/skills/prioritization-frameworks", - "./.claude/skills/product-requirements-from-structured-analysis", - "./.claude/skills/product-review", - "./.claude/skills/qa", - "./.claude/skills/release", - "./.claude/skills/release-notes", - "./.claude/skills/requirements-prioritization-with-p0-p1-p2-framework", - "./.claude/skills/scope-defense-using-time-cost-tradeoff-analysis", - "./.claude/skills/sprint-planning", - "./.claude/skills/stakeholder-risk-review-for-a-feature-or-prd", - "./.claude/skills/structured-requirements-from-conversation-transcripts", - "./.claude/skills/structured-requirements-from-design-assets", - "./.claude/skills/test-scenarios", - "./.claude/skills/user-stories-from-initiative-requirements", - "./.claude/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements", - "./.claude/skills/write-spec", - "./.claude/skills/wwas" - ] - }, - { - "name": "productize-design", - "description": "UX, prototypes, design systems, accessibility, product experience, interface analysis, and design handoff.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/acceptance-criteria-for-ui", - "./.claude/skills/accessibility-review", - "./.claude/skills/app-design-from-project-requirements", - "./.claude/skills/behavioral-guidelines", - "./.claude/skills/conflicting-stakeholder-requirements-to-balanced-design", - "./.claude/skills/design-critique", - "./.claude/skills/design-handoff", - "./.claude/skills/design-review", - "./.claude/skills/design-system", - "./.claude/skills/exec-feedback-without-context-to-actionable-design-requirements", - "./.claude/skills/executive-decks-from-quick-dirty-test-analysis", - "./.claude/skills/frontend-design", - "./.claude/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem", - "./.claude/skills/multi-step-workflow-optimization", - "./.claude/skills/multiple-interface-descriptions-from-a-single-image", - "./.claude/skills/pm-context-and-design-constraints", - "./.claude/skills/product-design-analysis-from-context-and-screenshots", - "./.claude/skills/prototype-creation-from-image-descriptions-and-app-info", - "./.claude/skills/sketch-descriptions-for-wireframes-from-product-ideas", - "./.claude/skills/solution-design-for-edge-cases-in-product-development", - "./.claude/skills/structured-json-descriptions-from-ui-screenshots", - "./.claude/skills/ux-edge-cases-from-product-briefs", - "./.claude/skills/ux-terminology-improvements-in-product-requirements" - ] - }, - { - "name": "productize-marketing", - "description": "Brand, positioning copy, messaging, market orientation, battlecards, launches, campaigns, and product marketing artifacts.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/brand-archetype-strategy", - "./.claude/skills/brand-equity-diagnostics", - "./.claude/skills/competitive-analysis-to-winning-positioning-strategy", - "./.claude/skills/competitive-brief", - "./.claude/skills/ctas-from-copywriting-strategies", - "./.claude/skills/demo-narratives-showing-user-goals", - "./.claude/skills/disruptive-strategy-generation-from-what-if-questions", - "./.claude/skills/industry-trend-strategy", - "./.claude/skills/market-orientation-audit", - "./.claude/skills/message-framing-and-comms-plan-designer", - "./.claude/skills/positioning-statements-from-competitive-analysis-and-value", - "./.claude/skills/press-releases-from-product-vision-working-backwards", - "./.claude/skills/strategy-curve-blue-ocean" - ] - }, - { - "name": "productize-operations", - "description": "Product operating cadence, governance, decision rights, meeting systems, policies, team workflows, and reusable product rituals.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/autoplan", - "./.claude/skills/conversation-summaries-from-meeting-transcripts", - "./.claude/skills/decision-rights-using-davci", - "./.claude/skills/draft-nda", - "./.claude/skills/meeting-agendas-from-meeting-descriptions", - "./.claude/skills/meeting-summaries-from-meeting-transcript-ideas-framework", - "./.claude/skills/operate", - "./.claude/skills/privacy-policy", - "./.claude/skills/product-refinement-session-planning", - "./.claude/skills/reinforcing-sequence-from-unstructured-items", - "./.claude/skills/remote-miro-workshops-from-transcripts-and-specs", - "./.claude/skills/task-list-optimization-and-contingency-based-project-planning", - "./.claude/skills/workshop-activity-design-from-problem-and-participant" - ] - }, - { - "name": "productize-stakeholder-communication", - "description": "Executive updates, stakeholder narratives, decks, meeting plans, influence, alignment, and difficult conversations.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/challenging-meeting-with-stakeholders", - "./.claude/skills/comms-review", - "./.claude/skills/crisis-communication-plan-from-outage-details-and-company", - "./.claude/skills/difficult-conversation-script-5-step-framework", - "./.claude/skills/executive-and-update-review", - "./.claude/skills/influence-strategies-from-cialdini-s-7-principles", - "./.claude/skills/map-power-dynamics-before-meetings", - "./.claude/skills/office-politics-with-machiavellian-strategy", - "./.claude/skills/potential-hidden-agenda-identification", - "./.claude/skills/presentation-narratives-from-conversation-transcripts", - "./.claude/skills/presentations-from-5-step-storytelling-framework", - "./.claude/skills/presentations-from-structured-content-and-context", - "./.claude/skills/product-strategy-review-from-draft-documents", - "./.claude/skills/product-vision", - "./.claude/skills/pyramid-structure-optimization-from-complex-text", - "./.claude/skills/roadmap-update", - "./.claude/skills/skimmable-writing-transformation", - "./.claude/skills/slide-decks-from-problem-statements-and-context", - "./.claude/skills/stakeholder-brief-clarification-and-problem-definition", - "./.claude/skills/stakeholder-moo-objections-and-product-derailment-risks", - "./.claude/skills/stakeholder-update", - "./.claude/skills/strategic-presentation-planning-from-topic-audience-and-time", - "./.claude/skills/structured-insight-extraction-from-conversation-transcripts", - "./.claude/skills/technical-translation-and-stakeholder-communication" - ] - }, - { - "name": "productize-ai-execution", - "description": "AI-builder handoff, technical specs, architecture briefs, verification, TDD, debugging, and agent-ready implementation planning.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/backend-design", - "./.claude/skills/dual-mode-ai-coding-assistant-staff-eng-intern", - "./.claude/skills/dx-review", - "./.claude/skills/eng-review", - "./.claude/skills/engineering-problem-solving-and-solution-structuring", - "./.claude/skills/features-reframing-and-projects-shape-up", - "./.claude/skills/implementation-notes", - "./.claude/skills/spec-writing", - "./.claude/skills/systematic-debugging", - "./.claude/skills/tdd", - "./.claude/skills/technical-architecture-brief-from-product-requirements-doc", - "./.claude/skills/verification", - "./.claude/skills/writing-plans" - ] - }, - { - "name": "productize-business-model", - "description": "Business model design, monetization, pricing, packaging, value capture, platform economics, and sustainability logic.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/business-flywheel-from-company-successes-and-failures", - "./.claude/skills/business-model-blindspots", - "./.claude/skills/business-model-design", - "./.claude/skills/lean-canvas", - "./.claude/skills/monetization-strategy", - "./.claude/skills/pricing-strategy", - "./.claude/skills/sustainable-business-model" - ] - }, - { - "name": "productize-venture-0-1", - "description": "Founder framing, venture opportunities, beachhead segments, market sizing, startup canvases, wedges, pivot decisions, and routing into Finance for fundraising or term-sheet math.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/0-1", - "./.claude/skills/beachhead-segment", - "./.claude/skills/defining-the-niche-from-user-input", - "./.claude/skills/market-opportunities-from-jobs-to-be-done-market-canvas", - "./.claude/skills/market-opportunity", - "./.claude/skills/market-sizing", - "./.claude/skills/product-ideas-from-user-responses", - "./.claude/skills/startup-canvas" - ] - }, - { - "name": "productize-all", - "description": "All Productize product-management and AI-builder skills.", - "source": "./", - "strict": false, - "skills": [ - "./.claude/skills/0-1", - "./.claude/skills/aarrr-growth-diagnostics", - "./.claude/skills/ab-test-analysis", - "./.claude/skills/acceptance-criteria-for-ui", - "./.claude/skills/accessibility-review", - "./.claude/skills/actionable-customer-interview-guides-from-research-topics", - "./.claude/skills/actionable-job-stories-from-interview-transcripts", - "./.claude/skills/actionable-product-improvements-from-survey-responses", - "./.claude/skills/actionable-research-briefs-from-problem-statements-and", - "./.claude/skills/actionable-user-profiles-with-tasks-and-constraints-from", - "./.claude/skills/actionable-user-research-decisions-from-project-insights", - "./.claude/skills/adaptive-planning-from-scenarios-to-strategic-actions", - "./.claude/skills/aging-research-insight-validation-before-reusing", - "./.claude/skills/ai-product-evaluation-from-recommendation-canvas-framework", - "./.claude/skills/analyze", - "./.claude/skills/analyze-feature-requests", - "./.claude/skills/app-aha-moment-identification-from-user-data-and-app", - "./.claude/skills/app-design-from-project-requirements", - "./.claude/skills/autoplan", - "./.claude/skills/backend-design", - "./.claude/skills/beachhead-segment", - "./.claude/skills/behavioral-guidelines", - "./.claude/skills/brainstorm", - "./.claude/skills/brand-archetype-strategy", - "./.claude/skills/brand-equity-diagnostics", - "./.claude/skills/bug-prioritization-against-work-in-progress", - "./.claude/skills/build-dashboard", - "./.claude/skills/business-flywheel-from-company-successes-and-failures", - "./.claude/skills/business-model-blindspots", - "./.claude/skills/business-model-design", - "./.claude/skills/business-strategy-creation-from-expert-strategic-thinking", - "./.claude/skills/capital-structure-financing", - "./.claude/skills/challenging-meeting-with-stakeholders", - "./.claude/skills/churn-reduction-from-customer-data-and-exit-survey-analysis", - "./.claude/skills/clustered-jtbd-forces-from-interview-data", - "./.claude/skills/cohort-analysis", - "./.claude/skills/comms-review", - "./.claude/skills/competitive-advantage-diagnostics-and-moat-strategy", - "./.claude/skills/competitive-analysis-to-winning-positioning-strategy", - "./.claude/skills/competitive-brief", - "./.claude/skills/competitive-parity-and-strategic-differentiation", - "./.claude/skills/complex-problem-structuring-into-actionable-recommendations", - "./.claude/skills/comprehensive-use-cases-from-user-input-for-product-strategy", - "./.claude/skills/conflicting-stakeholder-requirements-to-balanced-design", - "./.claude/skills/conversation-summaries-from-meeting-transcripts", - "./.claude/skills/create-viz", - "./.claude/skills/creative-solution-generation-from-de-bono-s-lateral-thinking", - "./.claude/skills/creative-solution-generation-from-metaphorical-thinking", - "./.claude/skills/crisis-communication-plan-from-outage-details-and-company", - "./.claude/skills/critical-flaws-in-product-requirements-tough-and-unreasonable", - "./.claude/skills/ctas-from-copywriting-strategies", - "./.claude/skills/customer-insights-extraction-from-interview-transcript-using", - "./.claude/skills/customer-journey-map-based-on-user-behavior-data", - "./.claude/skills/data-context-extractor", - "./.claude/skills/data-driven-research-plans-from-leadership-intuition", - "./.claude/skills/data-visualization", - "./.claude/skills/decision-making-with-the-gut-check-protocol", - "./.claude/skills/decision-reversibility-classification-from-first-principles", - "./.claude/skills/decision-rights-using-davci", - "./.claude/skills/defining-the-niche-from-user-input", - "./.claude/skills/demo-narratives-showing-user-goals", - "./.claude/skills/design-critique", - "./.claude/skills/design-handoff", - "./.claude/skills/design-review", - "./.claude/skills/design-system", - "./.claude/skills/detailed-project-plans-from-project-briefs", - "./.claude/skills/difficult-conversation-script-5-step-framework", - "./.claude/skills/disruptive-strategy-generation-from-what-if-questions", - "./.claude/skills/docs", - "./.claude/skills/dogfood", - "./.claude/skills/draft-nda", - "./.claude/skills/dual-mode-ai-coding-assistant-staff-eng-intern", - "./.claude/skills/dx-review", - "./.claude/skills/easy-signal-identification-from-product-assumption", - "./.claude/skills/effective-customer-interview-guides-for-any-topic", - "./.claude/skills/empathy-maps", - "./.claude/skills/eng-review", - "./.claude/skills/engineering-problem-solving-and-solution-structuring", - "./.claude/skills/event-tracking-schemas-from-ui-and-metrics-requirements", - "./.claude/skills/exec-feedback-without-context-to-actionable-design-requirements", - "./.claude/skills/executive-and-update-review", - "./.claude/skills/executive-decks-from-quick-dirty-test-analysis", - "./.claude/skills/explore-data", - "./.claude/skills/feature-impact-models-from-kpis-and-assumptions", - "./.claude/skills/feature-results-analysis-from-draft-to-final-report", - "./.claude/skills/features-reframing-and-projects-shape-up", - "./.claude/skills/finance-modeling-kernel", - "./.claude/skills/financial-markets-context", - "./.claude/skills/fragmented-user-research-synthesis-into-coherent-insights", - "./.claude/skills/framework-application-to-product-challenges-from-user-input", - "./.claude/skills/frontend-design", - "./.claude/skills/future-product-opportunities-from-market-inflection-points", - "./.claude/skills/group-decision-making-quality-review", - "./.claude/skills/grow", - "./.claude/skills/growth-loops", - "./.claude/skills/growth-project-generation-with-pioneer-migrator-settler", - "./.claude/skills/growth-strategy-synthesis-from-user-inputs", - "./.claude/skills/gtm-motions", - "./.claude/skills/gtm-strategy", - "./.claude/skills/ideal-customer-profile-icp-representative-for-x-product", - "./.claude/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem", - "./.claude/skills/implementation-notes", - "./.claude/skills/industry-trend-strategy", - "./.claude/skills/influence-strategies-from-cialdini-s-7-principles", - "./.claude/skills/innovation-decision-making-heuristics", - "./.claude/skills/innovative-idea-generation-from-project-parameters-and", - "./.claude/skills/innovative-idea-generation-from-structured-brainstorming", - "./.claude/skills/innovative-product-ideas-from-structured-brainstorming", - "./.claude/skills/interactive-intake-for-ost-inputs", - "./.claude/skills/lean-canvas", - "./.claude/skills/limit-based-product-strategy-from-problem-to-execution-plan", - "./.claude/skills/low-frequency-to-power-user-transition-strategy", - "./.claude/skills/managerial-finance-dcf", - "./.claude/skills/map-power-dynamics-before-meetings", - "./.claude/skills/market-opportunities-from-jobs-to-be-done-market-canvas", - "./.claude/skills/market-opportunity", - "./.claude/skills/market-orientation-audit", - "./.claude/skills/market-requirements-from-strategic-market-inputs", - "./.claude/skills/market-sizing", - "./.claude/skills/mece-analysis-and-logical-tree-from-list-items", - "./.claude/skills/meeting-agendas-from-meeting-descriptions", - "./.claude/skills/meeting-outcome-planning-and-stakeholder-alignment", - "./.claude/skills/meeting-summaries-from-meeting-transcript-ideas-framework", - "./.claude/skills/message-framing-and-comms-plan-designer", - "./.claude/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition", - "./.claude/skills/metrics-review", - "./.claude/skills/monetization-strategy", - "./.claude/skills/multi-step-workflow-optimization", - "./.claude/skills/multiple-interface-descriptions-from-a-single-image", - "./.claude/skills/netmba-competitor-analysis", - "./.claude/skills/north-star-metric", - "./.claude/skills/now-next-later-vision-roadmap-from-interview-synthesis", - "./.claude/skills/nps-feedback-for-prioritized-customer-experience-initiatives", - "./.claude/skills/offbeat-question-generation-from-any-topic", - "./.claude/skills/office-politics-with-machiavellian-strategy", - "./.claude/skills/okr-planning-from-vision-statements", - "./.claude/skills/onboarding-flow-optimization-from-product-data-to-user-success", - "./.claude/skills/operate", - "./.claude/skills/opportunity-solution-tree-from-input", - "./.claude/skills/outcome-roadmap", - "./.claude/skills/plg-growth-playbook", - "./.claude/skills/pm-context-and-design-constraints", - "./.claude/skills/pmf-review", - "./.claude/skills/positioning-statements-from-competitive-analysis-and-value", - "./.claude/skills/post-launch-feedback-into-v2-improvements-synthesis", - "./.claude/skills/post-launch-feedback-loop", - "./.claude/skills/potential-hidden-agenda-identification", - "./.claude/skills/prds-from-industry-and-feature-specifications", - "./.claude/skills/prds-from-product-information-and-assumptions", - "./.claude/skills/pre-mortem", - "./.claude/skills/presentation-narratives-from-conversation-transcripts", - "./.claude/skills/presentations-from-5-step-storytelling-framework", - "./.claude/skills/presentations-from-structured-content-and-context", - "./.claude/skills/press-releases-from-product-vision-working-backwards", - "./.claude/skills/pricing-strategy", - "./.claude/skills/prioritization-frameworks", - "./.claude/skills/privacy-policy", - "./.claude/skills/problem-framing-before-jumping-to-solutions", - "./.claude/skills/problem-statement-framing-from-conversation-transcript", - "./.claude/skills/product-assumptions-from-core-strategy-inputs", - "./.claude/skills/product-brainstorming", - "./.claude/skills/product-decision-analysis-from-anthropological-research", - "./.claude/skills/product-design-analysis-from-context-and-screenshots", - "./.claude/skills/product-feature-impact-sizing-from-metrics-and-usage-data", - "./.claude/skills/product-ideas-from-user-responses", - "./.claude/skills/product-market-fit-cycle", - "./.claude/skills/product-refinement-session-planning", - "./.claude/skills/product-requirements-from-structured-analysis", - "./.claude/skills/product-review", - "./.claude/skills/product-simplification-via-via-negativa-analysis", - "./.claude/skills/product-strategy-review-from-draft-documents", - "./.claude/skills/product-vision", - "./.claude/skills/proto-persona-profiles-from-user-research-and-market-data", - "./.claude/skills/prototype-creation-from-image-descriptions-and-app-info", - "./.claude/skills/pyramid-structure-optimization-from-complex-text", - "./.claude/skills/qa", - "./.claude/skills/raw-interview-transcript-cleanup", - "./.claude/skills/realistic-jtbd-interview-transcripts", - "./.claude/skills/reinforcing-sequence-from-unstructured-items", - "./.claude/skills/release", - "./.claude/skills/release-notes", - "./.claude/skills/remote-miro-workshops-from-transcripts-and-specs", - "./.claude/skills/requirements-prioritization-with-p0-p1-p2-framework", - "./.claude/skills/research-into-durable-competitive-moats", - "./.claude/skills/risk-return-cost-of-capital", - "./.claude/skills/risky-assumption-prioritization-for-rapid-validation", - "./.claude/skills/roadmap-update", - "./.claude/skills/robust-experiment-design-from-goals-and-systems", - "./.claude/skills/role-identity-decision-making-map", - "./.claude/skills/root-cause-and-consequence-analysis-from-a-question", - "./.claude/skills/scope-defense-using-time-cost-tradeoff-analysis", - "./.claude/skills/sketch-descriptions-for-wireframes-from-product-ideas", - "./.claude/skills/skimmable-writing-transformation", - "./.claude/skills/slide-decks-from-problem-statements-and-context", - "./.claude/skills/solution-anti-patterns-from-customer-problem-analysis", - "./.claude/skills/solution-design-for-edge-cases-in-product-development", - "./.claude/skills/spec-writing", - "./.claude/skills/sprint-planning", - "./.claude/skills/sql-queries", - "./.claude/skills/sql-query-from-requirements-and-data-tables", - "./.claude/skills/stakeholder-brief-clarification-and-problem-definition", - "./.claude/skills/stakeholder-decision-making-using-toc-thinking-process", - "./.claude/skills/stakeholder-moo-objections-and-product-derailment-risks", - "./.claude/skills/stakeholder-power-interest-and-influence-map", - "./.claude/skills/stakeholder-risk-review-for-a-feature-or-prd", - "./.claude/skills/stakeholder-update", - "./.claude/skills/startup-canvas", - "./.claude/skills/statistical-analysis", - "./.claude/skills/strategic-crux-diagnosis-and-strategy-design", - "./.claude/skills/strategic-decision-making-quality-review", - "./.claude/skills/strategic-moves-from-swot-pairings", - "./.claude/skills/strategic-presentation-planning-from-topic-audience-and-time", - "./.claude/skills/strategy-curve-blue-ocean", - "./.claude/skills/strategy-kernel-extraction-from-context", - "./.claude/skills/strategy-to-execution-bridge-for-ux-decisions", - "./.claude/skills/structured-decision-journals-from-decisions-and-context", - "./.claude/skills/structured-insight-extraction-from-conversation-transcripts", - "./.claude/skills/structured-interview-notes-from-transcript-using-flexible", - "./.claude/skills/structured-json-descriptions-from-ui-screenshots", - "./.claude/skills/structured-product-hypotheses-from-product-problems", - "./.claude/skills/structured-product-strategy-from-product-context", - "./.claude/skills/structured-requirements-from-conversation-transcripts", - "./.claude/skills/structured-requirements-from-design-assets", - "./.claude/skills/success-metrics-for-design-decisions", - "./.claude/skills/support-tickets-as-actionable-product-improvements", - "./.claude/skills/sustainable-business-model", - "./.claude/skills/synthesize-research", - "./.claude/skills/systematic-debugging", - "./.claude/skills/target-opportunity-selection-from-ost", - "./.claude/skills/task-list-optimization-and-contingency-based-project-planning", - "./.claude/skills/task-specific-product-strategy-design", - "./.claude/skills/tdd", - "./.claude/skills/technical-architecture-brief-from-product-requirements-doc", - "./.claude/skills/technical-translation-and-stakeholder-communication", - "./.claude/skills/test-scenarios", - "./.claude/skills/thesis-review", - "./.claude/skills/trade-off-analysis-from-feature-priority-and-effort-data", - "./.claude/skills/user-stories-from-initiative-requirements", - "./.claude/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements", - "./.claude/skills/ux-edge-cases-from-product-briefs", - "./.claude/skills/ux-terminology-improvements-in-product-requirements", - "./.claude/skills/validate-data", - "./.claude/skills/valuation-and-deal-pricing", - "./.claude/skills/value-chain-mapping-from-end-user-needs-to-core-value", - "./.claude/skills/venture-capital-deal-modeling", - "./.claude/skills/verification", - "./.claude/skills/visual-decision-making-review", - "./.claude/skills/workshop-activity-design-from-problem-and-participant", - "./.claude/skills/write-query", - "./.claude/skills/write-spec", - "./.claude/skills/writing-plans", - "./.claude/skills/wwas" - ] - } - ] -} diff --git a/.claude/productize-runtime.json b/.claude/productize-runtime.json deleted file mode 100644 index c9248e1f..00000000 --- a/.claude/productize-runtime.json +++ /dev/null @@ -1,57 +0,0 @@ -{ - "generated": true, - "host": "claude", - "display_name": "Claude Code", - "adapter_source": "hosts/claude.mjs", - "generated_skill_path": ".claude/skills/{skill}", - "sidecars": [ - { - "source": "bin/productize-artifact-log", - "install_name": "productize-artifact-log" - }, - { - "source": "bin/productize-completion-status", - "install_name": "productize-completion-status" - }, - { - "source": "bin/productize-config", - "install_name": "productize-config" - }, - { - "source": "bin/productize-context-restore", - "install_name": "productize-context-restore" - }, - { - "source": "bin/productize-context-save", - "install_name": "productize-context-save" - }, - { - "source": "bin/productize-registry-search", - "install_name": "productize-registry-search" - }, - { - "source": "bin/productize-routing.mjs", - "install_name": "productize-routing.mjs" - }, - { - "source": "bin/productize-runtime.mjs", - "install_name": "productize-runtime.mjs" - }, - { - "source": "bin/productize-session-log", - "install_name": "productize-session-log" - }, - { - "source": "bin/productize-skill-router", - "install_name": "productize-skill-router" - }, - { - "source": "bin/productize-update-check", - "install_name": "productize-update-check" - }, - { - "source": "bin/productize-workflow", - "install_name": "productize-workflow" - } - ] -} diff --git a/.claude/skills/0-1/SKILL.md b/.claude/skills/0-1/SKILL.md deleted file mode 100644 index e2af6ffc..00000000 --- a/.claude/skills/0-1/SKILL.md +++ /dev/null @@ -1,237 +0,0 @@ ---- -name: 0-1 -description: >- - Productize 0-1 orchestrator for turning a raw product idea or new capability bet into a - working first product slice. Use for founder, PM, CPO, AI product leader, or AI builder work - that must combine product framing, capability scoping, curated data, application setup, eval - design, eval runs, behavior analysis, fixes, and ship/learn decisions. ---- - - - -# 0-1 Product Build Loop - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `0-1` -- **Lifecycle**: Think -- **Category**: Venture / 0-1 -- **Primary artifact**: 0-1 product build brief with capability scope, curated data, app setup, eval matrix, behavior analysis, fixes, ship gate, and next learning loop - -Use this skill when the user wants to build a new product, create a first version, -turn a vague idea into a working capability, or reshape an existing product around a -new capability. This is not a strategy handoff. Run the product-build loop. - -## Core Principle - -0-1 product work is a loop, not a sequence ending in "handoff to build". - -The loop is: - -1. Scope capability and curate data. -2. Set up the application. -3. Design evals. -4. Run evals. -5. Analyze behavior and spot error patterns. -6. Apply fixes. -7. Repeat until the ship gate is met, then launch and learn. - -For AI products and agentic workflows, treat evals, traces, curated examples, edge -cases, and instrumentation as part of the product, not as a QA step after product -definition. - -## Artifact Format - -Use Markdown for short loop notes or repo-native docs. Use self-contained HTML -when the 0-1 work creates a long plan, visual comparison, eval dashboard, PR -explainer, implementation-notes file, or shareable review artifact. When the user -asks for running implementation notes during build, activate `$implementation-notes` -and keep the requested `implementation-notes.md` or `implementation-notes.html` -current as decisions and deviations arise. - -## Route Internally - -Use the narrowest Productize skill for each part of the loop: - -### 1. Scope Capability And Curate Data - -- `$product-ideas-from-user-responses` -- `$problem-framing-before-jumping-to-solutions` -- `$beachhead-segment` -- `$market-opportunity` -- `$competitive-analysis-to-winning-positioning-strategy` -- `$positioning-statements-from-competitive-analysis-and-value` -- `$pricing-strategy` -- `$monetization-strategy` -- `$product-assumptions-from-core-strategy-inputs` -- `$risky-assumption-prioritization-for-rapid-validation` -- `$data-context-extractor` - -Output: first capability, target user, job/pain, wedge, competitive position, -pricing/value-capture assumptions, input data, evidence gaps, high-risk assumptions, -and minimum useful dataset or examples. - -### 2. Set Up Application - -- `$app-design-from-project-requirements` -- `$frontend-design` -- `$backend-design` -- `$technical-architecture-brief-from-product-requirements-doc` -- `$writing-plans` -- `$tdd` -- `$implementation-notes` when the user asks for running notes during build - -Output: app shell, system boundaries, data flow, UI flow, state model, build plan, -and first implementation slice. - -### 3. Design Evals - -- `$test-scenarios` -- `$verification` -- `$acceptance-criteria-for-ui` -- `$robust-experiment-design-from-goals-and-systems` -- `$success-metrics-for-design-decisions` -- `$event-tracking-schemas-from-ui-and-metrics-requirements` - -Output: eval matrix, test scenarios, behavioral traces to inspect, acceptance gates, -instrumentation, and product success criteria. - -### 4. Run Evals - -- `$verification` -- `$test-scenarios` -- `$validate-data` -- `$ab-test-analysis` when there is experiment data - -Output: fresh evidence, pass/fail results, screenshots or trace evidence when -available, metric caveats, and unresolved risks. - -### 5. Analyze Behavior And Error Patterns - -- `$systematic-debugging` -- `$feature-results-analysis-from-draft-to-final-report` -- `$metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- `$post-launch-feedback-loop` -- `$support-tickets-as-actionable-product-improvements` - -Output: behavior pattern map, root causes, error clusters, missing data, product -confusion, UX friction, prompt/model failure modes, and priority fixes. - -### 6. Apply Fixes - -- `$tdd` -- `$frontend-design` -- `$backend-design` -- `$design-critique` -- `$verification` -- `$implementation-notes` when fixes interpret or depart from the spec - -Output: applied code/design/product changes when the host agent can edit files, -or a concrete fix plan with owners, files, tests, and verification steps when it -cannot. - -### 7. Ship And Learn - -- `$pre-mortem` -- `$release-notes` -- `$post-launch-feedback-loop` -- `$metrics-review` - -Output: ship/no-ship decision, launch notes, learning plan, telemetry review, and -next loop. - -## Gate Cadence - -Run the relevant Productize reviewer or gate at each decision point: - -| 0-1 move | Gate | -|---|---| -| Move 1: Scope capability and curate data | `$thesis-review` + `$product-review` | -| Move 2a: Design | `$design-review` | -| Move 2b: Architect | `$eng-review` | -| Move 2c: Spec | `$product-review` | -| Move 2d: Build | `$eng-review` + `$qa` | -| Move 3: Design evals | `$qa` + `$product-review` | -| Deploy | `$release` | -| Move 4: Run evals | `$qa` | -| Move 5: Analyze | `$eng-review` | -| Move 6: Apply fixes | `$design-review` + `$qa` | -| Move 7: Ship and learn | `$release` + `$docs` + `$comms-review` | - -## Operating Rules - -1. Do not stop after naming the idea, wedge, or PRD. Continue into capability, app, - eval, behavior, and fix planning unless the user explicitly asks to stop earlier. -2. The first capability must be small enough to build and evaluate. If it is too - broad, cut scope before writing the spec. -3. Define evals before claiming the app is ready. For AI products, include golden - examples, adversarial examples, human review criteria, and observable behavior. -4. If a repo is available and the user asked to build, make code changes through the - host agent. If no repo exists, produce the scaffold and build plan. -5. Every loop must end with one of: ship, repeat, pivot, pause, or kill. - -## Required Output - -Return: - -1. **0-1 Route**: selected internal skills and why. -2. **Capability Scope**: target user, job/pain, first capability, non-goals, and wedge. -3. **Curated Data / Evidence**: available inputs, needed examples, edge cases, and risky gaps. -4. **Application Setup**: UI, backend, data flow, state, implementation slice, and files or modules when a repo exists. -5. **Eval Matrix**: scenarios, acceptance gates, instrumentation, metrics, and review criteria. -6. **Run / Analyze / Fix Loop**: current eval result, behavior/error patterns, fixes applied or planned, and verification. -7. **Ship Gate**: ship, repeat, pivot, pause, or kill; include the next learning loop. - -If the user asks a broad 0-1 question, produce the first useful loop slice instead -of a generic venture strategy memo. diff --git a/.claude/skills/aarrr-growth-diagnostics/SKILL.md b/.claude/skills/aarrr-growth-diagnostics/SKILL.md deleted file mode 100644 index c8b9d2c7..00000000 --- a/.claude/skills/aarrr-growth-diagnostics/SKILL.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -name: aarrr-growth-diagnostics -description: >- - Diagnose product or startup growth using AARRR pirate metrics, CAC, LTV, channel - performance, activation, retention, referral, revenue, and growth engine fit. Use for funnel - leakage, growth bottlenecks, SaaS conversion, and go-to-market growth analysis. ---- - - - -# AARRR Growth Diagnostics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `aarrr-growth-diagnostics` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: AARRR growth diagnosis and prioritized growth action plan - -Use this skill when the user needs to understand where growth is leaking and which part of the growth system should be fixed first. - -Do not use it for broad market selection, brand narrative, or PMF loop decisions unless the immediate task is funnel diagnosis. - -## Core Funnel - -AARRR means: - -1. **Acquisition**: people arrive or become aware enough to visit, install, inquire, or start. -2. **Activation**: people experience first value or reach the product's "wow" moment. -3. **Retention**: people come back and continue receiving value. -4. **Referral**: people invite, share, advocate, or create word-of-mouth. -5. **Revenue**: people pay, expand, renew, or create monetizable value. - -Some businesses measure revenue before referral. Preserve the user's funnel order when it is intentional; otherwise use the sequence above. - -## Unit Economics - -Always inspect: - -- **CAC**: customer acquisition cost. How much the business spends to acquire a customer or unit. -- **LTV/CLV**: lifetime value. How much revenue or gross profit the customer generates over time. -- **Payback**: time required to recover CAC. -- **Channel cost and quality**: volume, cost, conversion, and retained value by channel. - -## Growth Engines - -Classify the current or intended engine: - -- **Sales-led**: human sales motion, qualification, pipeline, account expansion. -- **Marketing-led**: paid/owned/earned channels, content, campaigns, demand generation. -- **Product-led**: self-serve acquisition, activation, usage, expansion, virality. -- **Community-led**: community participation, advocacy, identity, peer learning, network effects. - -## Workflow - -1. **Map the funnel** - - Define the exact event for each AARRR stage. - - Use counts, rates, and time windows where possible. - -2. **Find the bottleneck** - - Compare stage conversion, drop-off, time-to-stage, and segment differences. - - Identify whether the constraint is traffic quality, onboarding, value delivery, habit, monetization, or advocacy. - -3. **Inspect channels** - - Evaluate each acquisition channel by volume, cost, conversion, retained users, and revenue quality. - - Watch for channels that look efficient at signup but fail at activation or retention. - -4. **Check activation** - - Define the first-value or "wow" moment. - - Compare retained versus churned users by activation actions, timing, and sequence. - -5. **Check retention** - - Use cohort retention when available. - - Distinguish product value failure from lifecycle communication, service, pricing, or expectation mismatch. - -6. **Check referral** - - Use viral growth factor: - - X = percent of users who invite others - - Y = average number of invites sent - - Z = percent of invitees who accept - - Viral factor = X * Y * Z - -7. **Prioritize interventions** - - Recommend fixing upstream only when downstream economics support it. - - Do not scale acquisition into weak activation or retention. - -## Output - -Return: - -- **Growth Model**: current engine and funnel definitions. -- **AARRR Scorecard**: counts, conversion rates, benchmark/target if known, confidence. -- **Leakage Diagnosis**: biggest bottleneck and evidence. -- **Channel Diagnosis**: volume, cost, conversion, quality, and CAC implications. -- **Unit Economics**: CAC, LTV/CLV, payback, and risks. -- **Activation/Retention/Referral Findings**: specific issues and opportunities. -- **Priority Moves**: ranked actions with expected mechanism, metric, owner if known, and time-to-signal. -- **Instrumentation Gaps**: missing events, cohorts, segments, or attribution. - -## Quality Bar - -- Do not optimize acquisition before checking activation and retention. -- Do not treat signups as success unless first value and retention are healthy. -- Separate vanity metrics from value metrics. -- Tie recommendations to measurable stage movement. diff --git a/.claude/skills/ab-test-analysis/SKILL.md b/.claude/skills/ab-test-analysis/SKILL.md deleted file mode 100644 index 9379bc8c..00000000 --- a/.claude/skills/ab-test-analysis/SKILL.md +++ /dev/null @@ -1,165 +0,0 @@ ---- -name: ab-test-analysis -description: >- - A/B Test Analysis. Use when evaluating A/B test results, checking statistical significance, - validating sample size, reading confidence intervals, or deciding whether to ship, extend, - or stop an experiment. ---- - - - -# A/B Test Analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ab-test-analysis` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: A/B test decision memo with statistical readout and ship, extend, or stop recommendation - -Use when evaluating A/B test results, checking statistical significance, validating sample size, reading confidence intervals, or deciding whether to ship, extend, or stop an experiment. - -## Productize Contract - -- **Primary lifecycle**: Measure -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: A/B test decision memo with statistical readout and ship, extend, or stop recommendation -- **Source method**: pm-skills-main/pm-data-analytics/skills/ab-test-analysis/SKILL.md - -## Method - -## A/B Test Analysis - -Evaluate A/B test results with statistical rigor and translate findings into clear product decisions. - -### Context - -You are analyzing A/B test results for **$ARGUMENTS**. - -If the user provides data files (CSV, Excel, or analytics exports), read and analyze them directly. Generate Python scripts for statistical calculations when needed. - -### Instructions - -1. **Understand the experiment**: - - What was the hypothesis? - - What was changed (the variant)? - - What is the primary metric? Any guardrail metrics? - - How long did the test run? - - What is the traffic split? - -2. **Validate the test setup**: - - **Sample size**: Is the sample large enough for the expected effect size? - - Use the formula: n = (Z2/2 x 2 x p x (1-p)) / MDE2 - - Flag if the test is underpowered (<80% power) - - **Duration**: Did the test run for at least 1-2 full business cycles? - - **Randomization**: Any evidence of sample ratio mismatch (SRM)? - - **Novelty/primacy effects**: Was there enough time to wash out initial behavior changes? - -3. **Calculate statistical significance**: - - **Conversion rate** for control and variant - - **Relative lift**: (variant - control) / control x 100 - - **p-value**: Using a two-tailed z-test or chi-squared test - - **Confidence interval**: 95% CI for the difference - - **Statistical significance**: Is p < 0.05? - - **Practical significance**: Is the lift meaningful for the business? - - If the user provides raw data, generate and run a Python script to calculate these. - -4. **Check guardrail metrics**: - - Did any guardrail metrics (revenue, engagement, page load time) degrade? - - A winning primary metric with degraded guardrails may not be a true win - -5. **Interpret results**: - - | Outcome | Recommendation | - |---|---| - | Significant positive lift, no guardrail issues | **Ship it** -- roll out to 100% | - | Significant positive lift, guardrail concerns | **Investigate** -- understand trade-offs before shipping | - | Not significant, positive trend | **Extend the test** -- need more data or larger effect | - | Not significant, flat | **Stop the test** -- no meaningful difference detected | - | Significant negative lift | **Don't ship** -- revert to control, analyze why | - -6. **Provide the analysis summary**: - ``` - ## A/B Test Results: [Test Name] - - **Hypothesis**: [What we expected] - **Duration**: [X days] | **Sample**: [N control / M variant] - - | Metric | Control | Variant | Lift | p-value | Significant? | - |---|---|---|---|---|---| - | [Primary] | X% | Y% | +Z% | 0.0X | Yes/No | - | [Guardrail] | ... | ... | ... | ... | ... | - - **Recommendation**: [Ship / Extend / Stop / Investigate] - **Reasoning**: [Why] - **Next steps**: [What to do] - ``` - -Think step by step. Save as markdown. Generate Python scripts for calculations if raw data is provided. - ---- - -### Further Reading - -- [A/B Testing 101 + Examples](https://www.productcompass.pm/p/ab-testing-101-for-pms) -- [Testing Product Ideas: The Ultimate Validation Experiments Library](https://www.productcompass.pm/p/the-ultimate-experiments-library) -- [Are You Tracking the Right Metrics?](https://www.productcompass.pm/p/are-you-tracking-the-right-metrics) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/acceptance-criteria-for-ui/SKILL.md b/.claude/skills/acceptance-criteria-for-ui/SKILL.md deleted file mode 100644 index 964b2ae4..00000000 --- a/.claude/skills/acceptance-criteria-for-ui/SKILL.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -name: acceptance-criteria-for-ui -description: >- - Acceptance criteria for UI. Use when the user needs a product workflow for technical related - to acceptance criteria for ui. Trigger terms: quality-assurance, ui, acceptance-criteria, - responsive-design, technical. ---- - - - -# Acceptance criteria for UI - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `acceptance-criteria-for-ui` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Acceptance criteria for UI UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Acceptance criteria for UI**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Acceptance criteria for UI. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Produce a testable UI acceptance-criteria and QA validation checklist for the provided UI context. -- Cover at minimum: -- Visual testing (default/state/responsive checks). -- Functional testing (primary action, loading, error handling, edge cases). -- Accessibility testing (keyboard, screen reader, contrast, ARIA/semantic checks). -- Browser/device compatibility. -- Pass/fail summary with issues, tester, and date. -- Keep checks specific and verifiable (observable behavior, measurable thresholds, concrete expected results). -- Use a checklist style suitable for QA execution. - -FORMAT -Return exactly this structure: - - -## QA Validation Checklist - -### Visual Testing -- [ ] [check] -- [ ] [check] - -### Functional Testing -- [ ] [check] -- [ ] [check] - -### Accessibility Testing -- [ ] [check] -- [ ] [check] - -### Browser Compatibility -- [ ] Chrome (latest): [result] -- [ ] Safari (latest): [result] -- [ ] Firefox (latest): [result] -- [ ] Edge (latest): [result] -- [ ] Safari iOS: [result] -- [ ] Chrome Android: [result] - -### Pass/Fail -**Overall Result:** [PASS or FAIL] -**Issues Found:** [list deviations or "None"] -**Tester:** [name] -**Date:** [date] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Checklist items are vague/non-testable (no clear expected behavior or measurable criteria). -- Any critical section (Visual, Functional, Accessibility, Browser Compatibility, Pass/Fail) is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/accessibility-review/SKILL.md b/.claude/skills/accessibility-review/SKILL.md deleted file mode 100644 index 3767bfaf..00000000 --- a/.claude/skills/accessibility-review/SKILL.md +++ /dev/null @@ -1,226 +0,0 @@ ---- -name: accessibility-review -description: >- - Run a WCAG 2.1 AA accessibility audit on a design or page. Use when asked to audit - accessibility, check a11y, determine whether something is accessible, or review color - contrast, keyboard navigation, touch target size, or screen reader behavior before handoff. ---- - - - -# Accessibility Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `accessibility-review` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Accessibility Review UX/design review with findings, constraints, fixes, and acceptance checks - -Audit a design or page for WCAG 2.1 AA accessibility compliance. - -## Argument Hint - -`` - -## Usage - -```text -/accessibility-review $ARGUMENTS -``` - -## Inputs - -Accept: -- Figma design URL. -- Live or local page URL. -- Screenshot. -- Written design description. -- HTML/CSS/component code. - -If the input is not inspectable, ask for the minimum missing artifact needed to assess contrast, keyboard behavior, touch targets, or screen reader behavior. - -## WCAG 2.1 AA Quick Reference - -### Perceivable - -- **1.1.1 Non-text Content**: meaningful images and icons need text alternatives. -- **1.3.1 Info and Relationships**: structure must be conveyed semantically, not only visually. -- **1.4.3 Contrast (Minimum)**: normal text at least 4.5:1; large text at least 3:1. -- **1.4.11 Non-text Contrast**: UI components and graphics at least 3:1. - -### Operable - -- **2.1.1 Keyboard**: all functionality available via keyboard. -- **2.4.3 Focus Order**: focus order is logical. -- **2.4.7 Focus Visible**: keyboard focus indicator is visible. -- **2.5.5 Target Size**: touch targets at least 44x44 CSS pixels where applicable. - -### Understandable - -- **3.2.1 On Focus**: focus does not trigger unexpected context changes. -- **3.3.1 Error Identification**: errors are clearly identified. -- **3.3.2 Labels or Instructions**: inputs have labels or instructions. - -### Robust - -- **4.1.2 Name, Role, Value**: UI components expose accessible names, roles, states, and values. - -## Testing Approach - -Use the strongest available method for the artifact: - -1. Automated scan when browser/page tooling is available. Treat this as partial coverage only. -2. Keyboard-only navigation: tab order, Enter/Space behavior, Escape behavior, arrow-key behavior where expected. -3. Screen reader review: accessible names, roles, landmarks, form labels, live regions, and reading order. -4. Color contrast verification for text and non-text UI. -5. Zoom/reflow check at 200 percent. -6. Touch target sizing for mobile or touch-first UI. - -If a design tool is connected, inspect color values, typography, spacing, and component dimensions directly. If a browser tool is connected, open the page and verify interactive behavior directly. - -If a project tracker is connected, offer to turn findings into tickets with severity, WCAG criterion, repro steps, and recommended fix. - -## Common Issues - -- Insufficient text or UI contrast. -- Missing form labels. -- Interactive elements unreachable by keyboard. -- Missing alt text for meaningful images. -- Focus traps in modals. -- Missing landmarks or heading structure. -- Auto-playing media without controls. -- Time limits without extension. -- Small or crowded touch targets. -- Icon-only controls without accessible names. - -## Severity - -- **Critical**: blocks task completion for users with disabilities or violates a core accessibility requirement. -- **Major**: creates significant friction or likely failure for a common assistive technology path. -- **Minor**: improvement needed, but workaround likely exists. - -## Output Format - -```markdown -## Accessibility Audit: [Design/Page Name] - -**Standard:** WCAG 2.1 AA -**Date:** [Date] - -### Summary - -**Issues found:** [X] -**Critical:** [X] -**Major:** [X] -**Minor:** [X] - -### Findings - -#### Perceivable - -| # | Issue | WCAG Criterion | Severity | Recommendation | -|---|---|---|---|---| -| 1 | [Issue] | [1.4.3 Contrast] | Critical | [Fix] | - -#### Operable - -| # | Issue | WCAG Criterion | Severity | Recommendation | -|---|---|---|---|---| -| 1 | [Issue] | [2.1.1 Keyboard] | Major | [Fix] | - -#### Understandable - -| # | Issue | WCAG Criterion | Severity | Recommendation | -|---|---|---|---|---| -| 1 | [Issue] | [3.3.2 Labels] | Minor | [Fix] | - -#### Robust - -| # | Issue | WCAG Criterion | Severity | Recommendation | -|---|---|---|---|---| -| 1 | [Issue] | [4.1.2 Name, Role, Value] | Major | [Fix] | - -### Color Contrast Check - -| Element | Foreground | Background | Ratio | Required | Result | -|---|---|---|---|---|---| -| [Body text] | [color] | [color] | [X]:1 | 4.5:1 | Pass/Fail | - -### Keyboard Navigation - -| Element | Tab Order | Enter/Space | Escape | Arrow Keys | -|---|---|---|---|---| -| [Element] | [Order] | [Behavior] | [Behavior] | [Behavior] | - -### Screen Reader - -| Element | Announced As | Issue | -|---|---|---| -| [Element] | [What screen reader should announce] | [Problem if any] | - -### Priority Fixes - -1. **[Critical fix]** - Affects [who] and blocks [what]. -2. **[Major fix]** - Improves [what] for [who]. -3. **[Minor fix]** - Nice to have. -``` - -## Rules - -- Start with contrast and keyboard access; these catch many high-impact issues. -- Be specific: cite the WCAG criterion, affected element, user impact, and fix. -- Do not claim full compliance from automated checks alone. -- When evidence is limited, say what could and could not be verified. -- Prioritize issues by user impact before cosmetic polish. diff --git a/.claude/skills/actionable-customer-interview-guides-from-research-topics/SKILL.md b/.claude/skills/actionable-customer-interview-guides-from-research-topics/SKILL.md deleted file mode 100644 index 79bcb0b0..00000000 --- a/.claude/skills/actionable-customer-interview-guides-from-research-topics/SKILL.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -name: actionable-customer-interview-guides-from-research-topics -description: >- - Actionable customer interview guides from research topics. Use when the user needs a product - workflow for user research related to actionable customer interview guides from research - topics. Trigger terms: user-research, interviews, discussion-guide. ---- - - - -# Actionable customer interview guides from research topics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `actionable-customer-interview-guides-from-research-topics` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Actionable customer interview guides from research topics research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Actionable customer interview guides from research topics**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: Actionable customer interview guides from research topics. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Create a comprehensive customer interview discussion guide for `{{TOPIC}}`. -- Follow Mom Test and Continuous Discovery Habits principles: -- Open-ended, behavior-based questions. -- Focus on past experiences over hypotheticals. -- No leading or biased phrasing. -- Cover current workflow, pain points, outcomes, and usage context. -- Structure the guide in sections: -- Introduction and warm-up. -- Current situation and workflow. -- Challenges and pain points. -- Desired outcomes and goals. -- Exploration of potential solutions (without pitching). -- Wrap-up and next steps. -- Within each section: -- Number all questions. -- Prioritize the most important questions first. -- Include concise interviewer prompts in `[brackets]` where useful. -- Start with a brief interviewer introduction and key reminders. - -FORMAT -Return exactly this structure: - - -[Brief interviewer introduction: interview purpose and key reminders] - -## Introduction and Warm-Up -1. [Question] -[Interviewer prompt in brackets if needed] - -## Current Situation and Workflow -1. [Question] -[Interviewer prompt in brackets if needed] - -## Challenges and Pain Points -1. [Question] -[Interviewer prompt in brackets if needed] - -## Desired Outcomes and Goals -1. [Question] -[Interviewer prompt in brackets if needed] - -## Exploration of Potential Solutions -1. [Question] -[Interviewer prompt in brackets if needed] - -## Wrap-Up and Next Steps -1. [Question] -[Interviewer prompt in brackets if needed] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Required sections are missing or questions are not numbered/prioritized. -- Questions are leading, hypothetical-first, or not behavior-based. -- Guide does not cover workflow, pain points, outcomes, and context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/actionable-job-stories-from-interview-transcripts/SKILL.md b/.claude/skills/actionable-job-stories-from-interview-transcripts/SKILL.md deleted file mode 100644 index cf190c7d..00000000 --- a/.claude/skills/actionable-job-stories-from-interview-transcripts/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: actionable-job-stories-from-interview-transcripts -description: >- - Actionable job stories from interview transcripts. Use when the user needs a product - workflow for user research related to actionable job stories from interview transcripts. - Trigger terms: user-research, jtbd, interviews. ---- - - - -# Actionable job stories from interview transcripts - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `actionable-job-stories-from-interview-transcripts` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Actionable job stories from interview transcripts research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Actionable job stories from interview transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INTERVIEW_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Actionable job stories from interview transcripts. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{INTERVIEW_TRANSCRIPT}}` to identify explicit and implicit user problems. -- Infer underlying needs from: -- Pain points, frustrations, inefficiencies. -- Context and background details. -- Goals, motivations, and desired outcomes. -- Workarounds and makeshift solutions. -- Generate job stories in this format: -- `When [situation], I want to [motivation], so I can [expected outcome].` -- Output only: -- A concise 2-3 sentence summary. -- A list of job stories grounded in transcript evidence. - -FORMAT -Return exactly this structure: - - - -[Brief summary of your analysis] - - -[Job story 1] -[Job story 2] -[Additional entries as needed] - - - -FAILURE -- ``, ``, or `` is missing or malformed. -- Job stories do not follow `When... I want... so I can...` structure. -- Job stories are generic or not grounded in transcript-derived problems. -- Summary is missing or not within 2-3 sentences. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/actionable-product-improvements-from-survey-responses/SKILL.md b/.claude/skills/actionable-product-improvements-from-survey-responses/SKILL.md deleted file mode 100644 index 79d12b82..00000000 --- a/.claude/skills/actionable-product-improvements-from-survey-responses/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: actionable-product-improvements-from-survey-responses -description: >- - Actionable product improvements from survey responses. Use when the user needs a product - workflow for user research related to actionable product improvements from survey responses. - Trigger terms: user-research, surveys, insights. ---- - - - -# Actionable product improvements from survey responses - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `actionable-product-improvements-from-survey-responses` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Actionable product improvements from survey responses research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Actionable product improvements from survey responses**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SURVEY_RESPONSES}} - - -GOAL -Produce a high-quality deliverable for: Actionable product improvements from survey responses. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{SURVEY_RESPONSES}}` to identify recurring themes and distinct user pain points. -- For each pain point, include: -- At least two supporting quotes from different responses where possible. -- One or more concrete, actionable improvement items. -- Ensure findings are evidence-based, specific, and focused on improving product/service/process outcomes. -- Identify multiple themes when the dataset supports it. - -FORMAT -Return exactly this structure: - - - -[Describe the pain point] - -- "[Relevant quote]" (Response #X) -- "[Relevant quote]" (Response #Y) - - -- [Action item 1] -- [Action item 2] - - -[Repeat `` for each identified theme] - - -FAILURE -- `` or `` schema is missing, malformed, or materially incomplete. -- Pain points are generic and not supported by response evidence. -- Any theme lacks at least two supporting quotes. -- Action items are vague, non-actionable, or not linked to the stated pain point. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/actionable-research-briefs-from-problem-statements-and/SKILL.md b/.claude/skills/actionable-research-briefs-from-problem-statements-and/SKILL.md deleted file mode 100644 index d7e334fd..00000000 --- a/.claude/skills/actionable-research-briefs-from-problem-statements-and/SKILL.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -name: actionable-research-briefs-from-problem-statements-and -description: >- - Actionable research briefs from problem statements and solutions. Use when the user needs a - product workflow for user research related to actionable research briefs from problem - statements and solutions. Trigger terms: user-research, research-brief, ux. ---- - - - -# Actionable research briefs from problem statements and solutions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `actionable-research-briefs-from-problem-statements-and` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Actionable research briefs from problem statements and solutions research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Actionable research briefs from problem statements and solutions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} -- {{PROPOSED_SOLUTION}} - - -GOAL -Produce a high-quality deliverable for: Actionable research briefs from problem statements and solutions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{PROBLEM_STATEMENT}}` and `{{PROPOSED_SOLUTION}}` to produce an actionable UX research brief. -- Include and connect the following components: -- Background context. -- Scope and key risks to investigate. -- Rough research timeline. -- Research type. -- Research methods (qualitative and/or quantitative as appropriate). -- Concrete deliverables. -- Expected outcomes, learnings, and measurement plan. -- Keep recommendations specific, feasible, and aligned to decision-making needs. -- Provide rationale for chosen research type/methods/timing. - -FORMAT -Return exactly this structure: - - -## Introduction -[Brief summary of problem and proposed solution] - -## Background Context -[Context and core issues] - -## Scope and Risks -[What the research will cover and key risks/challenges to validate] - -## Rough Timelines -[Phased timeline with approximate duration] - -## Type of Research -[Evaluative, generative, exploratory, validation, etc., with rationale] - -## Research Methods -[Methods, participants, and why they fit] - -## Research Deliverables -[Specific outputs from the research] - -## Expected Outcomes, Learnings, and Measurements -[What decisions this research should inform and how success will be measured] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Required brief components are missing or weakly specified. -- Methods are not aligned to the problem/solution or lack clear rationale. -- Deliverables/outcomes are generic and not decision-oriented. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/actionable-user-profiles-with-tasks-and-constraints-from/SKILL.md b/.claude/skills/actionable-user-profiles-with-tasks-and-constraints-from/SKILL.md deleted file mode 100644 index 840e07cb..00000000 --- a/.claude/skills/actionable-user-profiles-with-tasks-and-constraints-from/SKILL.md +++ /dev/null @@ -1,233 +0,0 @@ ---- -name: actionable-user-profiles-with-tasks-and-constraints-from -description: >- - Actionable user profiles with tasks and constraints from shallow personas. Use when the user - needs a product workflow for user research related to actionable user profiles with tasks - and constraints from shallow personas. Trigger terms: user-research, personas, ux. ---- - - - -# Actionable user profiles with tasks and constraints from shallow personas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `actionable-user-profiles-with-tasks-and-constraints-from` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Actionable user profiles with tasks and constraints from shallow personas research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Actionable user profiles with tasks and constraints from shallow personas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{EXISTING_PERSONA}} -- {{AVAILABLE_USER_DATA}} -- {{PRODUCT_CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Actionable user profiles with tasks and constraints from shallow personas. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Transform `{{EXISTING_PERSONA}}` into an actionable user profile using `{{AVAILABLE_USER_DATA}}` and `{{PRODUCT_CONTEXT}}`. -- Replace vague persona language with specific, observable details: -- Concrete tasks and success outcomes. -- Jobs-to-be-done (functional, emotional, social). -- Capabilities, constraints, and behavioral patterns. -- Grounded contextual scenarios. -- Design implications directly tied to profile evidence. -- Explicit research gaps and validation plan for missing/uncertain assumptions. -- Keep all claims evidence-linked; state assumptions when data is incomplete. - -FORMAT -Return exactly this structure: - - - -**Role:** [Specific job title and organizational context] -**Core Responsibility:** [What they're accountable for] -**Primary Goal:** [What success looks like in their role] - - - - -[List 5-7 specific tasks they need to accomplish related to this product: -- Example: "Create quarterly budget forecast for leadership review" -- Example: "Onboard new team members to project workflows within first week"] - - - -[List 3-5 emotional needs: -- Example: "Feel confident in decisions without analysis paralysis" -- Example: "Avoid embarrassment from missing important details"] - - - -[List 2-3 social needs: -- Example: "Be seen as data-driven and strategic by leadership" -- Example: "Maintain credibility with engineering team"] - - - - -**Technical Sophistication:** -[Describe their comfort with technology, tools they know, learning curve tolerance] - -**Domain Expertise:** -[Describe their knowledge of the problem domain, industry experience, specialized skills] - -**Decision Authority:** -[Describe what they can decide independently vs. what requires approval] - -**Time Availability:** -[Describe their time constraints, competing priorities, typical workflow rhythm] - -**Resources:** -[Describe what tools, data, people, budget they have access to] - - - -**Organizational Constraints:** -[List policies, processes, approval chains that limit their options] - -**Technical Constraints:** -[List system limitations, integrations, legacy tools they must work with] - -**Knowledge Constraints:** -[List gaps in their knowledge, areas where they need guidance] - -**Time Constraints:** -[List deadlines, recurring obligations, busy periods] - -**Resource Constraints:** -[List limitations in budget, headcount, tools, data access] - - - -**How They Currently Solve This Problem:** -[Describe their current workflow, tools used, workarounds, pain points] - -**Decision-Making Style:** -[Describe how they evaluate options, what evidence they trust, risk tolerance] - -**Collaboration Patterns:** -[Describe who they work with, communication preferences, meeting cadence] - -**Learning Preferences:** -[Describe how they prefer to learn new tools, documentation vs. experimentation] - - - - -**Situation:** [Specific context: when, where, why] -**Goal:** [What they're trying to accomplish] -**Constraints:** [What's limiting them] -**Current Approach:** [How they do it now] -**Pain Points:** [What goes wrong or feels hard] -**Success Criteria:** [What "good" looks like] - - - -[Repeat structure for 2-3 total scenarios covering different use cases] - - - - -[List 5-7 specific design implications from this user profile: -- "Must support quick, interrupted workflows due to frequent context-switching" -- "Should provide confidence-building validation since users fear making errors" -- "Must integrate with Slack since that's where they live all day"] - - - -[List specific things you don't know but should validate with real users: -- "How do they currently handle X scenario?" -- "What's their tolerance for Y type of complexity?" -- "How often do they encounter Z situation?"] - - - -[Describe how to validate this profile with real users: -- Proposed research methods -- Key questions to ask -- Behaviors to observe -- Success signals that profile is accurate] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Profile remains generic/buzzword-heavy and not actionable for design decisions. -- Jobs, constraints, scenarios, or implications are not grounded in available data. -- Research gaps/validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/actionable-user-research-decisions-from-project-insights/SKILL.md b/.claude/skills/actionable-user-research-decisions-from-project-insights/SKILL.md deleted file mode 100644 index 51b60c46..00000000 --- a/.claude/skills/actionable-user-research-decisions-from-project-insights/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: actionable-user-research-decisions-from-project-insights -description: >- - Actionable user research decisions from project insights. Use when the user needs a product - workflow for user research related to actionable user research decisions from project - insights. Trigger terms: user-research, decision-making, frameworks. ---- - - - -# Actionable user research decisions from project insights - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `actionable-user-research-decisions-from-project-insights` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Actionable user research decisions from project insights research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Actionable user research decisions from project insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_DESCRIPTION}} -- {{DEVELOPMENT_STAGE}} -- {{EVIDENCE_NEEDS}} -- {{SPLASH_ZONE_IMPACT}} - - -GOAL -Produce a high-quality deliverable for: Actionable user research decisions from project insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Apply the Reforge-style user insights decision framing to: -- `{{PROJECT_DESCRIPTION}}` -- `{{DEVELOPMENT_STAGE}}` -- `{{EVIDENCE_NEEDS}}` -- `{{SPLASH_ZONE_IMPACT}}` -- Produce a specific research decision description framed as a question. -- Ensure the decision question is: -- Concrete and visceral (not abstract). -- Specific to user, context, behavior, and decision consequence. -- Aligned to stage-appropriate evidence needs. -- Scoped to the stated splash-zone/impact. -- Include assumptions explicitly if required context is missing. - -FORMAT -Return exactly this structure: - - -[Use this space to think through and refine your decision description] - - - -[Write your final decision description here] - - -FAILURE -- `` or `` is missing, malformed, or materially incomplete. -- Decision description is not phrased as a researchable question. -- Language is vague/abstract and not specific to stage, evidence needs, or splash-zone impact. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/adaptive-planning-from-scenarios-to-strategic-actions/SKILL.md b/.claude/skills/adaptive-planning-from-scenarios-to-strategic-actions/SKILL.md deleted file mode 100644 index 52c301e3..00000000 --- a/.claude/skills/adaptive-planning-from-scenarios-to-strategic-actions/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: adaptive-planning-from-scenarios-to-strategic-actions -description: >- - Adaptive planning from scenarios to strategic actions. Use when the user needs a product - workflow for product strategy related to adaptive planning from scenarios to strategic - actions. Trigger terms: strategic-planning, facilitation, product-management, - decision-making, frameworks. ---- - - - -# Adaptive planning from scenarios to strategic actions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `adaptive-planning-from-scenarios-to-strategic-actions` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Adaptive planning from scenarios to strategic actions strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Adaptive planning from scenarios to strategic actions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_STATE}} -- {{PROJECTED_MESS}} -- {{IDEAL_FUTURE}} -- {{IDEAL_CURRENT_STATE}} - - -GOAL -Produce a high-quality deliverable for: Adaptive planning from scenarios to strategic actions. -Success metric: -- Produces a complete four-quadrant analysis and feedback loop grounded in the provided scenarios. -- Identifies concrete adjustments and capabilities to avoid the projected mess and enable the ideal future. -- Ends with a concise, actionable plan with specific next steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_STATE}}`, `{{PROJECTED_MESS}}`, `{{IDEAL_FUTURE}}`, and `{{IDEAL_CURRENT_STATE}}`; if missing data is critical, state assumptions explicitly. -- Address all four quadrants and the feedback loop, grounded in provided inputs. -- Keep analysis specific and actionable; avoid generic leadership or capability lists. -- Action plan must include concrete steps that bridge current to ideal while mitigating projected mess. - -FORMAT -Return exactly this structure: - - - -[Your analysis of the Current State] - - - -[Your analysis of the Projected Mess] - - - -[Your analysis of the Ideal Future] - - - -[Your analysis of the Ideal Current State] - - - - -[Your recommendations for current state adjustments] - - - -[Your recommendations for avoiding the projected mess] - - - -[Your recommendations for enabling the ideal future] - - - - -[Your concise summary and specific, actionable steps] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Feedback loop omits one of the three adjustment categories. -- Action plan lacks concrete, actionable steps linked to the quadrants. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/aging-research-insight-validation-before-reusing/SKILL.md b/.claude/skills/aging-research-insight-validation-before-reusing/SKILL.md deleted file mode 100644 index 9f8f35f7..00000000 --- a/.claude/skills/aging-research-insight-validation-before-reusing/SKILL.md +++ /dev/null @@ -1,320 +0,0 @@ ---- -name: aging-research-insight-validation-before-reusing -description: >- - Aging research insight validation before reusing. Use when the user needs a product workflow - for user research related to aging research insight validation before reusing. Trigger - terms: user-research, validation, insights. ---- - - - -# Aging research insight validation before reusing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `aging-research-insight-validation-before-reusing` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Aging research insight validation before reusing research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Aging research insight validation before reusing**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{EXISTING_RESEARCH}} -- {{CURRENT_CONTEXT}} -- {{TIME_SINCE_RESEARCH}} - - -GOAL -Produce a high-quality deliverable for: Aging research insight validation before reusing. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Evaluate research currency using `{{EXISTING_RESEARCH}}`, `{{CURRENT_CONTEXT}}`, and `{{TIME_SINCE_RESEARCH}}`. -- Assess decay factors (time, market, product, user base, competition, contextual/regulatory changes). -- Classify insights by confidence (`high`, `medium`, `low`) with evidence and caveats. -- Identify stable insight patterns vs decayed patterns. -- Propose validation research (quick validation + deeper follow-up), testable hypotheses, and prioritized research gaps. -- Provide clear guidance on what is safe to use now, what to use cautiously, and what to retire. -- Respect prior research investment while being explicit about limitations and assumptions. - -FORMAT -Return exactly this structure: - - - - -- Time since research: [X months/years] -- Decay risk: [Low/Medium/High] -- Reasoning: [Why time matters for this research] - - - -- Changes: [List significant market shifts] -- Impact on insights: [How these changes affect research validity] -- Decay risk: [Low/Medium/High] - - - -- Changes: [List how product has evolved] -- Impact on insights: [Which insights are now outdated] -- Decay risk: [Low/Medium/High] - - - -- Changes: [How users/segments have changed] -- Impact on insights: [Which user insights may no longer apply] -- Decay risk: [Low/Medium/High] - - - -- Changes: [How competitors have evolved] -- Impact on insights: [How this affects user expectations/behaviors] -- Decay risk: [Low/Medium/High] - - - -- Changes: [Regulatory, technology, environmental shifts] -- Impact on insights: [What's different now] -- Decay risk: [Low/Medium/High] - - - - - -[Insights that are likely still valid: - -**Insight:** [Original finding] - -**Type:** [Fundamental need / Core job / Deep motivation] - -**Why Still Valid:** -[Reasoning for confidence] - -**Evidence:** -[Any recent signals supporting this] - -**Caveat:** -[Any context to consider] - -**Recommended Use:** -[How to apply this insight today]] - - - -[Insights that should be validated: - -**Insight:** [Original finding] - -**Type:** [Behavior / Pain point / Preference / Workflow] - -**Decay Concern:** -[What might have changed] - -**Current Confidence:** [50-75%] - -**Validation Needed:** -[Specific questions to answer] - -**Quick Validation:** -[Lightweight way to check if still true] - -**Use As:** -[Hypothesis to test, not fact to assume]] - - - -[Insights that are likely outdated: - -**Insight:** [Original finding] - -**Why Likely Invalid:** -[Specific decay factors] - -**Current Confidence:** [<50%] - -**Recommendation:** -[Don't rely on this - research fresh] - -**New Research Needed:** -[What to study instead]] - - - - -**What Types of Insights Have Decayed:** -[Common patterns: e.g., "Tool-specific workflows are outdated" or "Pain points around X have been solved"] - -**What Remains Stable:** -[Common patterns: e.g., "Core job of [Y] hasn't changed" or "Fundamental need for [Z] still exists"] - -**Decay Acceleration Factors:** -[What makes insights go stale faster in this domain] - - - -**Critical Questions to Answer:** -1. [Question that would validate/invalidate high-priority insight] -2. [Question that would validate/invalidate high-priority insight] -3. [Question that would validate/invalidate high-priority insight] - -**Proposed Research Approach:** - -**Phase 1: Quick Validation (1-2 weeks)** -- Method: [Lightweight approach: surveys, analytics review, stakeholder interviews] -- Purpose: [Confirm or refute medium-confidence insights] -- Sample: [Who to include] -- Key questions: [List] - -**Phase 2: Deep Dive (3-4 weeks, if needed)** -- Method: [Rigorous approach: user interviews, observation, diary studies] -- Purpose: [Generate fresh insights on areas of uncertainty] -- Sample: [Who to include] -- Key questions: [List] - -**Decision Point:** -- After Phase 1: [Determine if Phase 2 is needed] -- Criteria: [What findings would trigger deeper research] - - - -[Convert old insights into testable hypotheses: - -**Old Insight:** [Original finding] - -**Current Hypothesis:** [Reformulated as testable statement] - -**Test:** [How to validate] - -**If True:** [What it means for design] - -**If False:** [What it means for design] - -**Alternative Hypotheses:** -[Other possibilities to consider]] - - - -**What We Don't Know:** -[List critical unknowns not covered by old research: -- New user segments -- New use cases -- New competitors/alternatives -- New technologies -- New constraints] - -**Priority:** -[Which gaps are most critical to fill] - -**Proposed Research:** -[How to fill each gap] - - - -**Insights You Can Use Today:** -[List high-confidence insights with caveats] - -**Use With Caution:** -[List medium-confidence insights with required validation] - -**Don't Use:** -[List low-confidence insights to discard] - - - -**Best Practices Going Forward:** -- Research expiration dating: [Label research with "valid until" or "revalidate by"] -- Decay indicators: [Track market/product changes that invalidate research] -- Continuous learning: [Lightweight ongoing research to keep insights fresh] -- Research library: [System for marking outdated research] -- Validation triggers: [Events that should trigger revalidation] - - - -**How to Present to Team:** -[Guidance for explaining which research to trust: -- Be transparent about confidence levels -- Explain decay factors -- Propose validation plan -- Don't dismiss old research entirely - use as starting point] - -**Research Debt Message:** -[Draft message explaining need for fresh research while respecting past investment] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Confidence classifications are unsupported by decay-factor reasoning. -- Validation plan lacks concrete questions, methods, or decision criteria. -- Safe-to-use guidance does not clearly separate `use now` / `use with caution` / `don't use`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/ai-product-evaluation-from-recommendation-canvas-framework/SKILL.md b/.claude/skills/ai-product-evaluation-from-recommendation-canvas-framework/SKILL.md deleted file mode 100644 index 39ccfb01..00000000 --- a/.claude/skills/ai-product-evaluation-from-recommendation-canvas-framework/SKILL.md +++ /dev/null @@ -1,223 +0,0 @@ ---- -name: ai-product-evaluation-from-recommendation-canvas-framework -description: >- - AI product evaluation from Recommendation Canvas framework. Use when the user needs a - product workflow for decision making related to ai product evaluation from recommendation - canvas framework. Trigger terms: pm, decision-making, ai-product, recommendation-canvas, - strategy. ---- - - - -# AI product evaluation from Recommendation Canvas framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ai-product-evaluation-from-recommendation-canvas-framework` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: AI product evaluation from Recommendation Canvas framework decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **AI product evaluation from Recommendation Canvas framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a complete, executive-ready AI Recommendation Canvas for a specific problem/persona, plus improvement suggestions and a go/no-go decision. -Success metric: -- Canvas is coherent, measurable, and defensible across business outcome, product outcome, solution hypothesis, and success metrics. -- Unknowns are explicitly marked; no invented facts. -- Includes 3-5 concrete improvement suggestions and a clear go/no-go recommendation. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required workflow: - 1. Gather/normalize available context and identify missing critical inputs. - 2. Tighten outcomes into SMART form. - 3. Build the canvas with explicit unknowns and assumptions. - 4. Add 3-5 improvement suggestions. - 5. Provide a go/no-go recommendation with rationale. -- If multiple personas exist, choose one primary persona and note secondary impacts. -- For regulated data, include compliance and data-minimization constraints. -- For generative AI use cases, include safety/evaluation/abuse-monitoring considerations. -- Distinguish risks to investigate (pre-decision) vs risks to monitor (post-decision). -- Keep language concise, outcome-first, and metric-linked. -- Do not invent facts; mark unknowns explicitly. - -FORMAT -Return exactly this structure: - -```md -# AI Recommendation Canvas - -## Product Name -- [Concise, memorable name] - -## Business Outcome -- [Direction][Metric][Outcome][Context][Acceptance Criteria] - -## Product Outcome -- [Direction][Metric][Outcome][Persona context][Acceptance] - -## The Problem Statement -### Problem Statement Narrative -- [Persona + context + constraints] -- [2-3 sentence first-person narrative] - -## Solution Hypothesis -### Hypothesis Statement -- **If we** ... -- **for** ... -- **then we will** ... - -### Tiny Acts of Discovery (Experiments) -- Viability: ... -- Value: ... -- Feasibility: ... -- Safety: ... - -### Proof-of-Life (Success Criteria) -- Quantitative: ... -- Qualitative: ... -- Operational: ... - -## Positioning Statement -### Value Proposition -**For** ... -**that need** ... -**[Product Name]** **is a** ... -**that** ... - -### Differentiation Statement -**Unlike** ... -**[Product Name]** **provides** ... - -## Assumptions & Unknowns -- ... - -## Issues/Risks to Investigate (PESTEL) -- Political: ... -- Economic: ... -- Social: ... -- Technological: ... -- Environmental: ... -- Legal: ... - -## Issues/Risks to Monitor (PESTEL) -- Political: ... -- Economic: ... -- Social: ... -- Technological: ... -- Environmental: ... -- Legal: ... - -## Value Justification -### Is this Valuable? -- [Absolutely yes / Yes with caveats / No with alternatives / Absolutely no] - -### Solution Justification (Executive-Ready) -1. Financial Impact โ€” ... -2. Strategic Fit โ€” ... -3. Customer Value โ€” ... -4. Operational Feasibility โ€” ... -5. Risk Mitigation โ€” ... - -## Success Metrics (SMART) -1. Efficiency โ€” ... -2. Quality โ€” ... -3. Adoption โ€” ... -4. Financial โ€” ... -5. Safety โ€” ... - -## Whatโ€™s Next (Strategic Steps) -1. Data Readiness โ€” ... -2. Prototype โ€” ... -3. Pilot โ€” ... -4. Scale โ€” ... -5. Governance โ€” ... -6. Commercialization โ€” ... -``` - - -1. [Improvement suggestion] -2. [Improvement suggestion] -3. [Improvement suggestion] -[Add 3-5 total] - - - -[Go / No-Go / Go with conditions] - [Brief rationale tied to outcomes, feasibility, and risk] - - -FAILURE -- Canvas is not rendered as a single Markdown code block. -- Required canvas sections are missing or materially incomplete. -- Missing `` section with 3-5 suggestions. -- Missing `` section. -- Claims are generic or not grounded in provided inputs. -- Unknowns/assumptions are present but not explicitly marked. diff --git a/.claude/skills/analyze-feature-requests/SKILL.md b/.claude/skills/analyze-feature-requests/SKILL.md deleted file mode 100644 index dc63a825..00000000 --- a/.claude/skills/analyze-feature-requests/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: analyze-feature-requests -description: >- - Analyze Feature Requests. Use when reviewing customer, sales, support, or stakeholder - feature requests and turning them into prioritized product decisions. ---- - - - -# Analyze Feature Requests - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `analyze-feature-requests` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Feature-request triage report with themes, strategic fit, effort/risk, and backlog recommendations - -Use when reviewing customer, sales, support, or stakeholder feature requests and turning them into prioritized product decisions. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: Discover -- **Primary artifact**: Feature-request triage report with themes, strategic fit, effort/risk, and backlog recommendations -- **Source method**: pm-skills-main/pm-product-discovery/skills/analyze-feature-requests/SKILL.md - -## Method - -## Analyze Feature Requests - -Categorize, evaluate, and prioritize customer feature requests against product goals. - -### Context - -You are analyzing feature requests for **$ARGUMENTS**. - -If the user provides files (spreadsheets, CSVs, or documents with feature requests), read and analyze them directly. If data is in a structured format, consider creating a summary table. - -### Domain Context - -Never allow customers to design solutions. Prioritize **opportunities (problems)**, not features. Use **Opportunity Score** (Dan Olsen) to evaluate customer-reported problems: Opportunity Score = Importance x (1 Satisfaction), normalized to 0-1. See the `prioritization-frameworks` skill for full details and templates. - -### Instructions - -The user will describe their product goal and provide feature requests. Work through these steps: - -1. **Understand the goal**: Confirm the product objective and desired outcomes that will guide prioritization. - -2. **Categorize requests into themes**: Group related requests together and name each theme. - -3. **Assess strategic alignment**: For each theme, evaluate how well it aligns with the stated goals. - -4. **Prioritize the top 3 features** based on: - - **Impact**: Customer value and number of users affected - - **Effort**: Development and design resources required - - **Risk**: Technical and market uncertainty - - **Strategic alignment**: Fit with product vision and goals - -5. **For each top feature**, provide: - - Rationale (customer needs, strategic alignment) - - Alternative solutions worth considering - - High-risk assumptions - - How to test those assumptions with minimal effort - -Think step by step. Save as markdown or create a structured output document. - ---- - -### Further Reading - -- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/analyze/SKILL.md b/.claude/skills/analyze/SKILL.md deleted file mode 100644 index a2a82683..00000000 --- a/.claude/skills/analyze/SKILL.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -name: analyze -description: >- - Answer data questions from quick lookups to full analyses. Use when looking up one metric, - investigating a trend or drop, comparing segments over time, or preparing a formal data - report for stakeholders. ---- - - - -# Analyze - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `analyze` -- **Lifecycle**: Design -- **Category**: Analytics -- **Primary artifact**: Analyze UX/design review with findings, constraints, fixes, and acceptance checks - -Answer a data question, from a quick lookup to a full analysis or formal report. - -## Argument Hint - -`` - -## Usage - -```text -/analyze -``` - -## Workflow - -### 1. Understand the Question - -Classify complexity: -- Quick answer: one metric, simple filter, factual lookup. -- Full analysis: trend, segment comparison, or driver investigation. -- Formal report: comprehensive investigation with methodology, caveats, and recommendations. - -Identify required metrics, dimensions, time ranges, filters, and output format. - -### 2. Gather Data - -If warehouse or analytics tools are connected: -1. Explore schemas and table meanings. -2. Write SQL or tool queries. -3. Execute and retrieve results. -4. Debug failures against the dialect and schema. -5. Run sanity checks before analyzing. - -If no data tool is connected: -- Ask for query results, CSV/XLSX, pasted table, or schema. -- If the user needs SQL to run manually, draft it with dialect assumptions. - -### 3. Analyze - -Calculate needed metrics, aggregations, comparisons, and rates. For complex questions, break the analysis into sub-questions. Identify patterns, outliers, anomalies, and segment drivers. - -### 4. Validate - -Before presenting, check: -- Row counts. -- Nulls and missing periods. -- Magnitude and range. -- Trend continuity. -- Aggregation totals. -- Metric denominator and filtering logic. - -Flag caveats rather than hiding uncertainty. - -### 5. Present Findings - -For quick answers: -- State the answer directly. -- Include method or query for reproducibility. - -For full analyses: -- Lead with the key finding. -- Support with tables and charts where useful. -- Note methodology and caveats. -- Suggest follow-up questions. - -For formal reports: -- Executive summary. -- Methodology. -- Detailed findings. -- Caveats and data quality notes. -- Recommendations. - -### 6. Visualize - -Use `data-visualization` for chart selection and `create-viz` when a chart artifact is needed. Use `build-dashboard` when the output needs multiple charts, filters, and a shareable HTML dashboard. diff --git a/.claude/skills/app-aha-moment-identification-from-user-data-and-app/SKILL.md b/.claude/skills/app-aha-moment-identification-from-user-data-and-app/SKILL.md deleted file mode 100644 index 0f9ec0fa..00000000 --- a/.claude/skills/app-aha-moment-identification-from-user-data-and-app/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: app-aha-moment-identification-from-user-data-and-app -description: >- - App aha moment identification from user data and app description. Use when the user needs a - product workflow for user research related to app aha moment identification from user data - and app description. Trigger terms: user-research, analytics, activation. ---- - - - -# App aha moment identification from user data and app description - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `app-aha-moment-identification-from-user-data-and-app` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: App aha moment identification from user data and app description research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **App aha moment identification from user data and app description**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{APP_DESCRIPTION}} -- {{USER_DATA}} - - -GOAL -Produce a high-quality deliverable for: App aha moment identification from user data and app description. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{APP_DESCRIPTION}}` and `{{USER_DATA}}` to identify potential app "aha moment" conditions. -- Perform: -- Qualitative analysis to surface 3-5 likely activation actions/conditions and why they matter. -- Quantitative analysis of retained vs churned behavior, including strongest predictor metrics. -- Session/timing-sequence analysis when session-level data is available. -- Synthesize findings into top "aha moment" conditions and supporting evidence. -- For each potential condition, provide comparative engagement metrics where possible: -- `% users who performed condition and were retained` -- `% users who did not perform condition and were not retained` -- If required data is unavailable, state that explicitly and provide best-supported directional inference. - -FORMAT -Return exactly this structure: - - -1. Qualitative Insights: - [List your qualitative findings here] - -2. Quantitative Insights: - [List your quantitative findings here] - -3. Potential "Aha Moment" Conditions: - [List the top 3-5 conditions you've identified] - -4. Supporting Metrics: - [Provide relevant metrics for each condition] - -5. Recommendations: - [Offer 2-3 actionable recommendations to improve user activation based on your analysis] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Potential aha conditions are not 3-5 or are not tied to both qualitative and quantitative evidence. -- Supporting metrics are missing, non-comparative, or not derived from provided data. -- Session/timing insights are omitted when session data exists, or fabricated when it does not. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/app-design-from-project-requirements/SKILL.md b/.claude/skills/app-design-from-project-requirements/SKILL.md deleted file mode 100644 index 2bbdf4ab..00000000 --- a/.claude/skills/app-design-from-project-requirements/SKILL.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -name: app-design-from-project-requirements -description: >- - App design from project requirements. Use when the user needs a product workflow for design - & prototyping related to app design from project requirements. Trigger terms: app-design, - ux, design-system, wireframing. ---- - - - -# App design from project requirements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `app-design-from-project-requirements` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: App design from project requirements UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **App design from project requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_DESCRIPTION}} -- {{TARGET_AUDIENCE}} - - -GOAL -Produce a high-quality deliverable for: App design from project requirements. -Success metric: -- Defines one clear core feature aligned to user needs and project goals. -- Provides a functional grayscale interface sketch focused on essential flow. -- Produces a minimal, consistent design system within stated constraints. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_DESCRIPTION}}` and `{{TARGET_AUDIENCE}}`; if details are missing, state assumptions explicitly. -- Identify exactly one core feature (the single highest-value user task). -- Keep interface sketch grayscale/function-first and limited to essential elements for the core feature. -- Design system must remain lightweight: - - Font sizes: 3-4 sizes total. - - Colors: 1 primary + up to 2-3 secondary colors. - - Spacing: one consistent scale. - - Button styles: 1-2 styles. -- Keep choices practical, internally consistent, and audience-appropriate. - -FORMAT -Return exactly this structure: - - - -[Insert your defined core feature here] - - - -[Describe your grayscale interface sketch here. Be specific about layout and essential elements.] - - - - -[List your chosen font sizes] - - - -[List your chosen colors] - - - -[Describe your spacing scale] - - - -[Describe your button style(s)] - - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- More than one core feature is proposed. -- `interface_sketch` emphasizes visual styling over functional layout. -- `font_sizes` has fewer than 3 or more than 4 sizes. -- `colors` exceeds 1 primary + 2-3 secondary colors. -- `button_styles` has fewer than 1 or more than 2 styles. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/autoplan/SKILL.md b/.claude/skills/autoplan/SKILL.md deleted file mode 100644 index c3cc2bc6..00000000 --- a/.claude/skills/autoplan/SKILL.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -name: autoplan -description: >- - Productize autoplan meta-runner. Use when the user wants the relevant Productize reviewers - and gates selected automatically for the current playbook stage, plan, implementation slice, - release, or production decision. ---- - - - -# Productize Autoplan - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `autoplan` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Autoplan gate matrix with current stage, gate set, review order, needed artifacts, and exit criteria - -Use this meta-runner to detect the current gate and run the relevant reviewers. It -does not replace `$0-1`, `$operate`, or `$grow`; it coordinates their reviewers. - -## Artifact Format - -If autoplan selects multiple gates or the output is meant for human review, prefer -a self-contained HTML gate matrix with reviewer status, stale evidence, required -artifacts, blockers, and next decisions. Use Markdown for a short route call. - -## Gate Detection - -- New bet, wedge, positioning, pricing, or scope: `$thesis-review` + `$product-review` -- UX, UI, prototype, handoff, accessibility, or design system: `$design-review` -- Architecture, data flow, implementation plan, technical risk, or build readiness: `$eng-review` -- Testability, acceptance checks, evals, or production defects: `$qa` -- Deploy, ship, changelog, versioning, rollback, or launch readiness: `$release` -- README, docs, guides, API docs, migration notes, or support docs: `$docs` -- API, CLI, SDK, integration, examples, or developer onboarding: `$dx-review` -- Executive update, customer announcement, stakeholder narrative, or launch comms: `$comms-review` -- Running implementation notes, spec deviations, build-time tradeoffs, or open questions: `$implementation-notes` - -## Required Output - -Return: - -1. **Current Gate**: playbook stage, evidence available, and what decision is blocked. -2. **Reviewer Set**: reviewers/gates to run now, skipped gates, and why. -3. **Review Order**: sequence, dependencies, and stale artifacts to refresh. -4. **Artifacts Needed**: source docs, diffs, screenshots, metrics, traces, or examples each reviewer needs. -5. **Exit Criteria**: what must be clear before the playbook can continue. diff --git a/.claude/skills/backend-design/SKILL.md b/.claude/skills/backend-design/SKILL.md deleted file mode 100644 index 4da21326..00000000 --- a/.claude/skills/backend-design/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: backend-design -description: >- - Design backend architecture for implementation with API contracts, data model changes, - service boundaries, security, and observability. ---- - - - -# Backend Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `backend-design` -- **Lifecycle**: Design -- **Category**: AI Execution -- **Primary artifact**: Backend Design UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to design robust backend changes before implementation. - -## The Process - -### Step 1: Define backend objective - -Clarify: -- business objective -- service boundary -- latency/reliability expectations - -### Step 2: Define API and contract changes - -Specify: -- endpoints/events -- request/response schemas -- error model and status mapping - -### Step 3: Define data model and migrations - -Document: -- schema changes -- migration strategy -- backward-compatibility approach - -### Step 4: Define security and observability - -Include: -- authn/authz requirements -- rate limiting/abuse controls -- logging, metrics, tracing -- alerting conditions - -### Step 5: Define rollout and verification - -Provide: -- phased rollout or feature flags -- rollback strategy -- verification checks and commands - -## Output Format - -```markdown -# [Feature Name] Backend Design Spec - -## Objective -- Goal: -- Service boundary: - -## API Contracts -- Endpoint/event definitions: -- Request/response schema: -- Error model: - -## Data Model -- Schema changes: -- Migration plan: -- Compatibility notes: - -## Security and Reliability -- Authn/authz: -- Abuse controls: -- Reliability constraints: - -## Observability -- Logs: -- Metrics: -- Traces: -- Alerts: - -## Rollout and Verification -- Rollout plan: -- Rollback plan: -- Verification commands/evidence: -``` - -## Quality Bar - -- Contracts must be explicit and testable -- Migration and rollback must be present for schema changes -- Verification must include observable evidence - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/.claude/skills/beachhead-segment/SKILL.md b/.claude/skills/beachhead-segment/SKILL.md deleted file mode 100644 index ec44b637..00000000 --- a/.claude/skills/beachhead-segment/SKILL.md +++ /dev/null @@ -1,226 +0,0 @@ ---- -name: beachhead-segment -description: >- - Beachhead Segment. Use when choosing the first market segment, entry wedge, launch audience, - early ICP, or 0-to-1 customer focus. ---- - - - -# Beachhead Segment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `beachhead-segment` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Beachhead segment decision brief with scoring, wedge rationale, and expansion path - -Use when choosing the first market segment, entry wedge, launch audience, early ICP, or 0-to-1 customer focus. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: Growth -- **Primary artifact**: Beachhead segment decision brief with scoring, wedge rationale, and expansion path -- **Source method**: pm-skills-main/pm-go-to-market/skills/beachhead-segment/SKILL.md - -## Method - -## Overview -Identify the first beachhead market segment for product launch. This skill evaluates potential market segments against key criteria to find your initial winning segment that enables fast PMF validation and adjacent expansion. - -## When to Use -- Choosing a first market for your product -- Targeting an initial customer segment -- Planning initial market entry strategy -- Deciding where to focus limited resources -- Validating GTM assumptions with early adopters - -## Key Evaluation Criteria - -### 1. Burning Pain Point -Does this segment experience an acute, unmet problem? -- Daily frustration with the status quo -- Significant productivity loss or cost impact -- Emotional urgency to find a solution -- Current workarounds are expensive or fragile -- Problem is getting worse over time - -### 2. Willingness to Pay -Does this segment have budget and motivation to pay for a solution? -- Documented budget allocation for this problem area -- ROI is clear and compelling (value > cost) -- Economic impact of problem justifies solution cost -- Decision-maker has autonomy or influence over budget -- No free or DIY alternatives that fully satisfy need - -### 3. Winnable Market Share -Can you realistically capture 60-70% of this segment in 3-18 months? -- Segment is large enough but not oversaturated -- Limited competition or easy differentiation -- Market players are fragmented or complacent -- Your product has clear competitive advantage -- You have unique access or distribution advantage - -### 4. Referral Potential -Will customers naturally refer or recommend to others? -- Segment contains professional communities -- Customers interact with adjacent segments (expansion opportunity) -- High word-of-mouth culture in this industry -- Network effects within the segment -- Solving problem for one creates demand in adjacent segments - -## How It Works - -### Step 1: List Potential Segments -Brainstorm all possible target segments: -- Industry verticals (SaaS, healthcare, manufacturing, etc.) -- Company size (SMB, mid-market, enterprise) -- Job titles or roles -- Geographic regions -- Use cases or use-case variations -- Customer maturity level - -### Step 2: Research Pain Points -Validate burning pain in each segment: -- Customer interviews and discovery calls -- Problem validation through surveys -- Market research and analyst reports -- Competitor positioning and customer reviews -- Quantify cost/impact of the problem -- Identify current workarounds and limitations - -### Step 3: Assess Willingness to Pay -Determine budget and economic viability: -- Segment's budget for this problem category -- ROI calculation (value gained vs cost) -- Current spending on solutions or workarounds -- Budget decision-making process -- Typical deal size expectations -- Pricing sensitivity in the segment - -### Step 4: Evaluate Winnability -Assess realistic market share potential: -- Total addressable market (TAM) size -- Competitive landscape and positioning -- Your differentiation or unfair advantage -- Distribution access to this segment -- Time and resources required -- Market growth and momentum - -### Step 5: Identify Referral Pathways -Map expansion opportunities: -- Adjacent segments that reference segment influences -- Network effects within the segment -- Professional communities and associations -- Customer-to-customer recommendations -- Natural expansion path to adjacent markets -- Viral or network effects from solving core pain - -### Step 6: Select Beachhead -Choose your primary launch segment: -- Highest combined score across four criteria -- Most achievable for your current resources -- Shortest path to PMF and revenue -- Best reference for adjacent expansion -- Most enthusiastic early customer cohort - -## Input Format -Use $ARGUMENTS to pass: -- Product description and capabilities -- Initial market research and validation data -- Potential segment options -- Constraints and limitations -- Timeline and resource constraints -- Current customer data or feedback - -## Output -A beachhead segment analysis including: -- Top 3-5 recommended segments with scoring -- Primary beachhead segment recommendation -- Pain point validation and evidence -- Willingness to pay assessment and pricing guidance -- Realistic market share and revenue projections -- Referral and expansion pathways to adjacent segments -- 90-day customer acquisition plan for beachhead -- Post-beachhead expansion roadmap - -## Framework -Based on Geoffrey Moore's beachhead market strategy in "Crossing the Chasm." Focuses on finding the smallest winnable, referenceable market that validates PMF and enables expansion. - -## Tips -- Start absurdly specific. A niche beachhead is better than a vague mass market -- Choose the segment most likely to evangelize your solution -- Validate all four criteria with at least 10 customer interviews -- Select segment with fastest path to revenue and references -- Ensure beachhead can reference to adjacent market segments -- Focus all resources on dominating the beachhead (not diluting efforts) -- Plan exit from beachhead only after 60%+ market share - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/behavioral-guidelines/SKILL.md b/.claude/skills/behavioral-guidelines/SKILL.md deleted file mode 100644 index 7a462933..00000000 --- a/.claude/skills/behavioral-guidelines/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: behavioral-guidelines -description: >- - Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or - refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and - define verifiable success criteria. ---- - - - -# Behavioral Guidelines - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `behavioral-guidelines` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Behavioral Guidelines UX/design review with findings, constraints, fixes, and acceptance checks - -Behavioral guidelines to reduce common LLM coding mistakes on LLM coding pitfalls. - -**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment. - -## 1. Think Before Coding - -**Do not assume. Do not hide confusion. Surface tradeoffs.** - -Before implementing: -- State your assumptions explicitly. If uncertain, ask. -- If multiple interpretations exist, present them instead of picking silently. -- If a simpler approach exists, say so. Push back when warranted. -- If something is unclear, stop. Name what is confusing. Ask. - -## 2. Simplicity First - -**Minimum code that solves the problem. Nothing speculative.** - -- No features beyond what was asked. -- No abstractions for single-use code. -- No flexibility or configurability that was not requested. -- No error handling for impossible scenarios. -- If you write 200 lines and it could be 50, rewrite it. - -Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. - -## 3. Surgical Changes - -**Touch only what you must. Clean up only your own mess.** - -When editing existing code: -- Do not improve adjacent code, comments, or formatting. -- Do not refactor things that are not broken. -- Match existing style, even if you would do it differently. -- If you notice unrelated dead code, mention it instead of deleting it. - -When your changes create orphans: -- Remove imports, variables, functions, and files that your changes made unused. -- Do not remove pre-existing dead code unless asked. - -The test: Every changed line should trace directly to the user's request. - -## 4. Goal-Driven Execution - -**Define success criteria. Loop until verified.** - -Transform tasks into verifiable goals: -- "Add validation" -> "Write tests for invalid inputs, then make them pass." -- "Fix the bug" -> "Write a test that reproduces it, then make it pass." -- "Refactor X" -> "Ensure tests pass before and after." - -For multi-step tasks, state a brief plan: - -```text -1. [Step] -> verify: [check] -2. [Step] -> verify: [check] -3. [Step] -> verify: [check] -``` - -Strong success criteria let you loop independently. Weak criteria such as "make it work" require constant clarification. diff --git a/.claude/skills/brainstorm/SKILL.md b/.claude/skills/brainstorm/SKILL.md deleted file mode 100644 index d467259b..00000000 --- a/.claude/skills/brainstorm/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: brainstorm -description: >- - Brainstorm a product topic with a sharp, opinionated thinking partner. Use for problem - exploration, opportunity areas, product ideas, assumption testing, strategy exploration, and - capturing next steps after a conversational session. ---- - - - -# Brainstorm - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `brainstorm` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Brainstorm research brief with evidence, insight clusters, assumptions, and next validation steps - -Brainstorm a product topic with a sharp, opinionated thinking partner. This is a conversation, not a report. - -## Argument Hint - -`` - -## Usage - -```text -/brainstorm $ARGUMENTS -``` - -## Workflow - -### 1. Understand the Starting Point - -Classify the prompt: -- Problem: start with problem exploration. -- Half-formed idea: start with assumption testing. -- Broad question: start with strategy exploration. -- Constraint: start with solution ideation. -- Vague instinct: start with problem exploration. - -Ask one framing question, then dive in. Do not front-load an intake form. - -### 2. Pull Context - -If connected, use docs, analytics, project tracker, chat, or research repositories to ground the brainstorm in prior work and data. If tools are not connected, work from what the PM provides. - -### 3. Run the Session - -Use the `product-brainstorming` behavior: -- Be a sparring partner, not a scribe. -- Push past the first idea. -- Use frameworks only when useful. -- Name traps directly. -- Shift between divergent and convergent thinking. - -Session rhythm: -1. Frame. -2. Diverge. -3. Provoke. -4. Converge. -5. Capture. - -### 4. Close the Session - -When the PM signals wrap-up or the conversation reaches a natural stopping point, summarize: -- 2-5 key ideas. -- Strongest direction and why. -- Riskiest assumption. -- Single most useful next step. -- Parked ideas. - -## Follow-Up Options - -Offer only relevant next artifacts: -- One-pager or spec. -- Opportunity solution tree. -- Research plan. -- Competitive brief. - -## Rules - -- Do not generate a 20-item idea list and walk away. -- One good question can beat five suggestions. -- Take positions. -- Stop when there are 2-3 strong directions and a clear next step. diff --git a/.claude/skills/brand-archetype-strategy/SKILL.md b/.claude/skills/brand-archetype-strategy/SKILL.md deleted file mode 100644 index c32c0320..00000000 --- a/.claude/skills/brand-archetype-strategy/SKILL.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -name: brand-archetype-strategy -description: >- - Define brand narrative, voice, imagery, symbols, and channel storytelling using brand - archetypes. Use for brand strategy, minimum viable brand, narrative consistency, archetype - selection, personal brand positioning, and brand story design. ---- - - - -# Brand Archetype Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `brand-archetype-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Brand Archetype Strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user needs to make a brand story more coherent, memorable, and strategically expressive. - -Do not use it for measuring brand health, campaign scoring, or growth funnel diagnosis unless the task includes brand narrative or identity choices. - -## Core Idea - -Brand archetypes are familiar narrative patterns that help people understand what a brand stands for. The archetype should shape the brand story, language, imagery, content, and channel behavior. - -In a digital environment, a brand can express a primary archetype with supporting archetypes across channels and customer-journey moments. The blend must still feel intentional. - -## Archetype Set - -Use these archetypes as the working set: - -- **Innocent**: purity, goodness, happiness, trust, simplicity, honesty. -- **Sage**: knowledge, wisdom, truth, expertise, interpretation, teaching. -- **Explorer**: discovery, freedom, adventure, individuality, curiosity. -- **Outlaw**: rebellion, disruption, rule breaking, radical change. -- **Magician**: transformation, vision, charisma, making dreams possible. -- **Hero**: courage, challenge, strength, competition, perseverance. -- **Creator**: imagination, invention, beauty, experimentation, originality. -- **Ruler**: control, order, authority, responsibility, power, structure. -- **Caregiver**: care, protection, comfort, support, empathy, commitment. -- **Everyperson**: belonging, friendship, practicality, down-to-earth connection. -- **Jester**: play, entertainment, cleverness, lightness, spontaneity. -- **Lover**: intimacy, pleasure, beauty, passion, relationship, sensuality. - -## Workflow - -1. **Clarify the strategic base** - - Identify mission, promise, intended experience, and desired movement. - - Capture target audience, category, competitors, and current perception. - -2. **Infer candidate archetypes** - - Map audience motivation and brand ambition to 2-4 plausible archetypes. - - Reject archetypes that sound attractive but conflict with product reality, culture, or proof. - -3. **Choose a primary archetype** - - Select one dominant archetype for memory structure and consistency. - - Explain why it fits the audience, category tension, promise, and evidence. - -4. **Define supporting archetypes** - - Add supporting archetypes only when they serve specific journey moments, channels, or audiences. - - Specify where each supporting archetype appears and where it must not appear. - -5. **Translate into expression** - - Define voice, vocabulary, imagery, behavior, content themes, rituals, and proof points. - - Include language to use and language to avoid. - -6. **Stress test consistency** - - Check whether the archetype makes the brand more distinctive. - - Check whether the archetype can survive product, support, sales, hiring, and community touchpoints. - -## Output - -Return: - -- **Brand Context**: audience, category, current perception, desired shift. -- **Archetype Recommendation**: primary archetype and 1-2 optional supporting archetypes. -- **Rationale**: fit with mission, promise, audience motivation, and category opportunity. -- **Narrative Platform**: core story, tension, promise, and proof. -- **Expression System**: voice, words, imagery, symbols, content themes, behaviors. -- **Journey/Channel Map**: how the archetype shows up across key touchpoints. -- **Do/Don't Rules**: concrete creative and messaging guardrails. -- **Consistency Risks**: where the archetype may break down. - -## Quality Bar - -- Do not choose archetypes by taste alone. -- Avoid making every brand a Hero, Sage, or Creator by default. -- Do not dilute the brand with a random archetype mix. -- Tie archetype choices to observable brand behavior and customer meaning. diff --git a/.claude/skills/brand-equity-diagnostics/SKILL.md b/.claude/skills/brand-equity-diagnostics/SKILL.md deleted file mode 100644 index fecc8255..00000000 --- a/.claude/skills/brand-equity-diagnostics/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: brand-equity-diagnostics -description: >- - Diagnose brand health and brand equity using awareness, familiarity, associations, and Brand - Asset Valuator dimensions. Use for brand performance, differentiation, relevance, esteem, - knowledge, brand strength, brand stature, and brand portfolio diagnosis. ---- - - - -# Brand Equity Diagnostics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `brand-equity-diagnostics` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Brand Equity Diagnostics strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user needs to assess whether a brand is healthy, distinctive, valuable, or at risk. - -Do not use it for brand voice creation, creative campaign selection, or growth funnel diagnosis unless the task is explicitly about brand equity. - -## Core Models - -Brand equity comes from marketing effects uniquely attributable to the brand name. Diagnose it through: - -- **Awareness and familiarity**: people know the brand and can recognize or recall it. -- **Associations**: people hold strong, favorable, and unique associations. -- **Behavioral reality**: customers are often apathetic, low-attention, and not deeply loyal. -- **Availability**: the brand is mentally and physically easy to notice and buy. - -Use Brand Asset Valuator (BAV) as the main diagnostic frame: - -- **Differentiation**: how distinct and meaningfully different the brand feels. -- **Relevance**: how appropriate and useful the brand is for the audience. -- **Esteem**: how respected and well-regarded the brand is. -- **Knowledge**: how familiar and understood the brand is. - -Interpret: - -- **Brand Strength** = Differentiation + Relevance. This is the future-facing signal. -- **Brand Stature** = Esteem + Knowledge. This is the current-status signal. - -## BAV Quadrants - -- **Leadership**: high strength, high stature. Defend distinctiveness and availability while avoiding complacency. -- **Unrealized or Emerging Potential**: high strength, low stature. Build awareness, distribution, credibility, and repetition. -- **Eroding Potential**: low strength, high stature. The brand is known but losing distinctiveness or relevance. -- **New or Unfocused**: low strength, low stature. Clarify meaning, audience, proof, and salience. - -## Workflow - -1. Clarify the category, audience, market, and competitor set. -2. Gather evidence: surveys, brand tracking, search, share of voice, reviews, win/loss, social listening, sales feedback, usage, pricing power. -3. Score or qualitatively rate awareness/familiarity, associations, differentiation, relevance, esteem, and knowledge. -4. Place the brand in the BAV quadrant. -5. Explain the main equity problem: - - unknown - - known but not distinctive - - distinctive but not relevant - - relevant but not respected - - respected but not salient - - strong but hard to buy -6. Recommend strategic actions for mental availability, physical availability, distinctive assets, association building, and proof. - -## Output - -Return: - -- **Evidence Base**: what data was used and what is missing. -- **Brand Equity Snapshot**: awareness/familiarity and association diagnosis. -- **BAV Assessment**: D/R/E/K ratings with rationale. -- **Quadrant Placement**: leadership, unrealized/emerging potential, eroding potential, or new/unfocused. -- **Primary Equity Problem**: the root brand health issue. -- **Strategic Implications**: what to protect, build, fix, or stop doing. -- **Action Plan**: concrete moves across communications, product experience, distribution, distinctive assets, and measurement. -- **Tracking Metrics**: leading and lagging brand indicators. - -## Quality Bar - -- Do not assume customers want a deep relationship with the brand. -- Distinguish fame from esteem, and awareness from clear associations. -- Do not recommend "more content" unless it builds a specific association or availability gap. -- Tie brand actions to measurable equity dimensions. diff --git a/.claude/skills/bug-prioritization-against-work-in-progress/SKILL.md b/.claude/skills/bug-prioritization-against-work-in-progress/SKILL.md deleted file mode 100644 index 68f932e6..00000000 --- a/.claude/skills/bug-prioritization-against-work-in-progress/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: bug-prioritization-against-work-in-progress -description: >- - Bug prioritization against work in progress. Use when the user needs a product workflow for - decision making related to bug prioritization against work in progress. Trigger terms: pm, - decision-making, prioritization, bugs, triage. ---- - - - -# Bug prioritization against work in progress - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `bug-prioritization-against-work-in-progress` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Bug prioritization against work in progress delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Bug prioritization against work in progress**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{BUG_DESCRIPTION}} -- {{CURRENT_WORK}} -- {{PLANNED_WORK}} - - -GOAL -Determine whether a reported bug should take priority over current and planned work, then provide a triage decision. -Success metric: -- Provides clear reasoning and YES/NO decision for both prioritization questions. -- Final decision is logically consistent with those two answers. -- Uses only provided bug/current/planned work context. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip either required question: - 1. Is this bug more important than current work? - 2. Is this bug more important than planned next work? -- For each question, include concise reasoning before the YES/NO answer. -- Apply decision rule strictly: - - If both answers are `NO` -> `Do not prioritize fixing this bug now`. - - If either answer is `YES` -> `Proceed to further classification`. -- Keep reasoning grounded in bug impact, user/business risk, and delivery tradeoffs from provided context. - -FORMAT -Return exactly this structure: - - -Reasoning: [Your reasoning here] -Answer: [YES/NO] - - - -Reasoning: [Your reasoning here] -Answer: [YES/NO] - - - -[Your decision here: either "Do not prioritize fixing this bug now" or "Proceed to further classification"] - - -FAILURE -- Missing ``, ``, or `` section. -- Missing reasoning or missing YES/NO answer for either question. -- Final decision contradicts the required decision rule. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/build-dashboard/SKILL.md b/.claude/skills/build-dashboard/SKILL.md deleted file mode 100644 index 402fda21..00000000 --- a/.claude/skills/build-dashboard/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: build-dashboard -description: >- - Build an interactive HTML dashboard with charts, filters, and tables. Use when creating an - executive KPI overview, turning query results into a shareable report, building a monitoring - snapshot, or combining multiple charts and filters in one browser-openable file. ---- - - - -# Build Dashboard - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `build-dashboard` -- **Lifecycle**: Design -- **Category**: Analytics -- **Primary artifact**: Build Dashboard UX/design review with findings, constraints, fixes, and acceptance checks - -Build a browser-openable interactive HTML dashboard with KPI cards, charts, filters, tables, and professional styling. - -## Argument Hint - -` [data source]` - -## Usage - -```text -/build-dashboard [data source] -``` - -## Workflow - -### 1. Understand Requirements - -Determine: -- Purpose: executive overview, operational monitoring, deep-dive analysis, team report. -- Audience. -- Key metrics. -- Filter dimensions. -- Data source: query, pasted data, CSV/XLSX, or sample data. - -### 2. Gather Data - -If warehouse, analytics, or spreadsheet tools are connected, query or parse the data and embed results as JSON. - -If only a description is provided, create realistic sample data and clearly label it as sample data. - -### 3. Design Layout - -Default pattern: -- Header with title and filters. -- 2-4 KPI cards. -- 1-3 charts for trends and breakdowns. -- Sortable detail table. -- Footer with data date and source. - -Adapt layout to the content. Do not force a table if the data is already summarized. - -### 4. Build HTML - -Generate one HTML file with: -- Semantic HTML. -- Responsive CSS Grid or Flexbox. -- KPI cards. -- Chart containers. -- Filter controls. -- Sortable and paginated table if needed. -- Embedded JSON data. -- JavaScript class or module to handle filters, charts, KPIs, and table updates. - -Use Chart.js or another lightweight chart library. If the dashboard must work offline, vendor or inline the library. If using CDN, state that internet access is required. - -### 5. Add Interactivity - -Include: -- Dropdown and date filters. -- Shared filter state that updates all cards, charts, and tables. -- Sortable table columns. -- Tooltip formatting. -- Number formatting for currency, percentage, and large numbers. - -### 6. Performance Rules - -- Under 1,000 rows: embed raw data. -- 1,000-10,000 rows: embed data but pre-aggregate charts where useful. -- 10,000-100,000 rows: embed aggregates and a table sample. -- Over 100,000 rows: recommend BI tooling, pagination, or server-backed dashboard. - -Limit visible table rows and avoid rebuilding unnecessary DOM on filter changes. - -### 7. Verify - -Open the generated HTML in the browser when browser tooling is available. Check layout, console errors, filters, charts, and responsive behavior. - -## Output Rules - -- Save with a descriptive filename. -- Include where the file was written. -- Note whether data is real or sample. -- Explain how to swap in real data if sample data was used. diff --git a/.claude/skills/business-flywheel-from-company-successes-and-failures/SKILL.md b/.claude/skills/business-flywheel-from-company-successes-and-failures/SKILL.md deleted file mode 100644 index ec4c0287..00000000 --- a/.claude/skills/business-flywheel-from-company-successes-and-failures/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: business-flywheel-from-company-successes-and-failures -description: >- - Business flywheel from company successes and failures. Use when the user needs a product - workflow for product strategy related to business flywheel from company successes and - failures. Trigger terms: strategy, flywheel, hedgehog-concept, retrospectives, - business-model. ---- - - - -# Business flywheel from company successes and failures - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `business-flywheel-from-company-successes-and-failures` -- **Lifecycle**: Strategize -- **Category**: Business Model -- **Primary artifact**: Business flywheel from company successes and failures business-model memo with value capture logic, risks, and next tests - -Use this skill to run the Productize prompt contract for **Business flywheel from company successes and failures**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY_INFO}} -- {{SUCCESSES}} -- {{DISAPPOINTMENTS}} - - -GOAL -Produce a high-quality deliverable for: Business flywheel from company successes and failures. -Success metric: -- Produces a 4โ€“6 component flywheel grounded in successes and disappointments. -- Explains the causal loop and how it reinforces outcomes. -- Connects the flywheel to Hedgehog Concept alignment. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY_INFO}}`, `{{SUCCESSES}}`, and `{{DISAPPOINTMENTS}}`; if information is missing, state assumptions explicitly. -- Identify 4โ€“6 flywheel components only; consolidate if more. -- Describe the causal loop explicitly (component -> component). -- Validate the flywheel against successes and disappointments (explain fit and gaps). -- Map the flywheel to the Hedgehog Concept circles. -- Keep outputs specific and evidence-grounded; avoid generic platitudes. - -FORMAT -Return exactly this structure: - - - -List the 4โ€“6 key components you've identified. - - - -Describe the flywheel, explaining how each component leads to the next in a self-reinforcing loop. - - - -Explain how the flywheel aligns with and explains the company's successes. - - - -Describe how the flywheel provides insights into the company's disappointments or failures. - - - -Discuss how the flywheel aligns with the three circles of the Hedgehog Concept. - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Number of flywheel components is outside 4โ€“6. -- Flywheel sketch does not show a clear causal loop. -- Alignment sections are generic or not tied to provided inputs. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/business-model-blindspots/SKILL.md b/.claude/skills/business-model-blindspots/SKILL.md deleted file mode 100644 index 8033e325..00000000 --- a/.claude/skills/business-model-blindspots/SKILL.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -name: business-model-blindspots -description: >- - Audit hidden assumptions and cognitive barriers in a business model. Use when a founder, - executive, strategist, or product team may be trapped by product-centric thinking, marketing - myopia, dominant logic, outdated assumptions, unclear customer need, a failing or - unexpectedly successful business model, or asks "what are we missing", "why is this model - not working", "what business are we really in", or "challenge our assumptions". ---- - - - -# Business Model Blindspots - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `business-model-blindspots` -- **Lifecycle**: Discover -- **Category**: Business Model -- **Primary artifact**: Business Model Blindspots business-model memo with value capture logic, risks, and next tests - -Expose the mental models, product-centric assumptions, and outdated theories that -block business model innovation. - -## Argument Hint - -`` - -## Usage - -```text -/business-model-blindspots $ARGUMENTS -``` - -## Core Rule - -Do not start by proposing a new business model. First make the current theory visible: -what the team believes about customers, needs, markets, technology, capabilities, -economics, and identity. - -Load `references/diagnostic-questions.md` for detailed diagnostic questions. - -Load `references/output-format.md` when producing a formal audit or workshop artifact. - -## Workflow - -### 1. Reconstruct the Current Theory - -Identify the implicit beliefs behind the model: - -- Who the customer, user, buyer, payer, and beneficiary are. -- What need or job the business exists to serve. -- What the organization believes it gets paid for. -- What capabilities it believes matter most. -- What market, technology, regulation, or behavior assumptions must remain true. -- What the organization believes it is and is not allowed to become. - -### 2. Detect Product-Centric Framing - -Look for: - -- Defining the business by the current product category. -- Treating substitutes or non-consumption as irrelevant. -- Assuming growth because the market or population grows. -- Assuming technical superiority guarantees demand. -- Confusing customer need with current product form. - -Reframe from product to underlying customer need or job. - -### 3. Test the Theory for Fitness - -Check whether assumptions: - -- Fit observable reality. -- Fit each other. -- Are known and understood by decision-makers. -- Are being tested continuously. - -Warning signs: - -- Unexpected failure. -- Unexpected success. -- Rapid growth that changes the business. -- Market, technology, regulation, or customer behavior shifts. -- Persistent exceptions explained away as edge cases. - -### 4. Identify Dominant Logic Traps - -Surface decision rules such as: - -- "Our customers are always..." -- "We make money by..." -- "The three things that matter are..." -- "We cannot serve..." -- "Partners/users/suppliers will never..." - -Challenge each rule with counterexamples, alternative segments, and changed -conditions. - -### 5. Produce an Assumption Audit - -Default output: - -1. Current theory of the business. -2. Product-centric or market-myopic framing risks. -3. Hidden assumptions table. -4. Contradictions and warning signs. -5. Reframed customer need/job. -6. Tests to validate or falsify the most dangerous assumptions. - -## Output Rules - -- Separate observations from interpretations. -- Do not call an assumption wrong unless there is evidence. -- Mark unknowns as unknowns and turn them into tests. -- Focus on business model consequences, not generic strategy critique. -- When the user asks for a redesign, run the audit first, then hand off to - `business-model-design`. diff --git a/.claude/skills/business-model-blindspots/references/diagnostic-questions.md b/.claude/skills/business-model-blindspots/references/diagnostic-questions.md deleted file mode 100644 index e86b608d..00000000 --- a/.claude/skills/business-model-blindspots/references/diagnostic-questions.md +++ /dev/null @@ -1,60 +0,0 @@ -# Diagnostic Questions - -Use these questions to make hidden business model assumptions explicit. - -## Customer and Need - -- Who is the customer? -- Who is the user? -- Who is the buyer? -- Who is the payer? -- Who benefits but does not pay? -- What job or need does the business actually serve? -- What would customers do if this product disappeared? -- Which substitutes, workarounds, or non-consumption patterns matter? - -## What the Business Gets Paid For - -- What exactly do customers pay for? -- Is payment tied to product ownership, access, usage, outcome, risk reduction, time saved, status, data, or convenience? -- Could a different actor pay for the same value? -- Are revenue streams aligned with the strongest value created? - -## Environment - -- What must be true about market growth, customer behavior, technology, regulation, competitors, distribution, or infrastructure? -- Which assumptions are no longer being tested because they feel obvious? -- What external change would break the current model? -- What external change would make an ignored model attractive? - -## Mission and Identity - -- What business do we believe we are in? -- What business are customers effectively hiring us for? -- What would we refuse to do because it feels "not us"? -- Is that refusal strategic discipline or inherited identity? - -## Capabilities - -- What are the core competencies that make the model work? -- Which capabilities are assumed to be unique but may no longer be? -- Which capabilities could be redeployed into another model? -- Which required capabilities are missing but hidden by optimism? - -## Dominant Logic Shortcuts - -Ask leaders to complete: - -- "The three most important things in this business are..." -- "Our customers care most about..." -- "The market will never..." -- "We cannot make money unless..." -- "The winning model in this category is..." -- "Our real advantage is..." - -Then challenge: - -- What evidence supports this? -- When was it last true? -- What counterexample would make us revise it? -- Which new entrant would reject this assumption? diff --git a/.claude/skills/business-model-blindspots/references/output-format.md b/.claude/skills/business-model-blindspots/references/output-format.md deleted file mode 100644 index 199e8148..00000000 --- a/.claude/skills/business-model-blindspots/references/output-format.md +++ /dev/null @@ -1,41 +0,0 @@ -# Business Model Blindspots Output - -```markdown -## Business Model Blindspots: [Company / Model] - -### Current Theory of the Business -| Area | Current Belief | Evidence | Confidence | -|---|---|---|---| -| Customer / user / payer | | | | -| Need or job served | | | | -| Revenue logic | | | | -| Core capabilities | | | | -| Market assumptions | | | | -| Identity / mission | | | | - -### Product-Centric Framing Risks -| Risk | Current Framing | Better Need-Based Framing | -|---|---|---| - -### Hidden Assumptions -| Assumption | Why It Matters | Evidence For | Evidence Against | Test | -|---|---|---|---|---| - -### Warning Signs -| Signal | Interpretation | What To Check Next | -|---|---|---| - -### Reframed Business Definition -[Define the business by customer need/job, not product category.] - -### Priority Tests -1. [Assumption] -> [test] -> [decision threshold] -2. [Assumption] -> [test] -> [decision threshold] -3. [Assumption] -> [test] -> [decision threshold] -``` - -## Severity Guidance - -- **High**: If false, the business model fails or needs a major pivot. -- **Medium**: If false, the business model still works but economics, channel, or positioning change. -- **Low**: Useful to clarify but not decision-critical. diff --git a/.claude/skills/business-model-design/SKILL.md b/.claude/skills/business-model-design/SKILL.md deleted file mode 100644 index c0ae4b54..00000000 --- a/.claude/skills/business-model-design/SKILL.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -name: business-model-design -description: >- - Design, compare, or document business models using the right canvas for the situation. Use - when a founder, product team, strategist, or innovation team asks to fill a business model - canvas, lean canvas, platform canvas, value creation and capture model, revenue/cost logic, - customer/user/payer model, or variants of "what is the business model", "how does this make - money", "which canvas should I use", "turn this idea into a business model", or "compare - these business models". ---- - - - -# Business Model Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `business-model-design` -- **Lifecycle**: Strategize -- **Category**: Business Model -- **Primary artifact**: Business Model Design business-model memo with value capture logic, risks, and next tests - -Create a working business model artifact, not a generic strategy essay. A business -model describes how an organization creates, delivers, and captures value. - -## Argument Hint - -`` - -## Usage - -```text -/business-model-design $ARGUMENTS -``` - -## Core Rule - -Choose the canvas based on the user's situation, then produce a filled-in canvas with -clear assumptions, open questions, and validation priorities. - -Load `references/canvas-selection.md` when choosing between canvas types. - -Load `references/canvas-templates.md` before creating blank templates, filled-in -canvases, visual layouts, tables, or printable artifacts. It contains the canonical -field labels for the standard, lean, and platform canvases. - -Load `references/business-model-output-rules.md` when comparing models, creating -handoff-ready outputs, or translating a canvas into experiments. - -Use the matching `assets/*.html` file when the user asks for a printable, visual, or -browser-openable canvas: - -- `assets/standard-business-model-canvas.html` -- `assets/lean-business-model-canvas.html` -- `assets/platform-business-model-canvas.html` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `business model canvas`, `bmc`, `all modes`, `value proposition mode`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Identify the Business Model Context - -Determine: - -- Existing company, new venture, corporate startup, platform, or sustainability - redesign. -- Customer, user, buyer, payer, producer, consumer, owner, and partner roles. -- What value is created, for whom, how it is delivered, and how value is captured. -- Whether the user wants a blank template, a filled canvas, a critique, or a - before/after redesign. - -If the user only gives a product or technology, ask what customer/user problem it -addresses before filling the model. - -### 2. Select the Canvas - -- **Standard Business Model Canvas**: use for most companies and product/service - business models. -- **Lean Business Model Canvas**: use for early-stage ventures, corporate startups, - unknown markets, and concepts that need problem/solution/risk validation. -- **Platform Business Model Canvas**: use for multi-sided platforms, marketplaces, - ecosystems, and models where several stakeholder groups exchange value. - -If two canvases apply, pick the primary one and add a short note showing what the -secondary lens would reveal. - -### 3. Fill the Canvas - -For each field: - -- Write concrete content, not slogans. -- Separate known facts from assumptions. -- Name the stakeholder explicitly. -- Link revenue streams to payer behavior and costs to required activities/resources. -- Avoid product-centric framing when the field should describe a customer need, - transaction, or job. - -### 4. Test Internal Coherence - -Check: - -- Does the value proposition match the customer segment and channel? -- Are key activities/resources/partners sufficient to deliver the value proposition? -- Does revenue logic match who receives value and who pays? -- Does the cost structure reflect the actual operating model? -- For platforms, are value transactions balanced for all sides? -- For lean canvases, are the highest-risk assumptions visible and testable? - -### 5. Produce the Output - -Default output: - -1. **Canvas selection** with rationale. -2. **Filled canvas** in editable Markdown table form. -3. **Coherence check**: strongest fit, weakest link, hidden assumption. -4. **Validation priorities**: 3-5 experiments or evidence gaps. -5. **Next decision**: what the team should decide or test next. - -## Output Rules - -- Preserve the exact canvas field labels from `references/canvas-templates.md`. -- Do not rename canvas fields unless the user asks for a custom artifact. -- Do not copy long source passages. Use canonical labels and original analysis. -- If facts are missing, mark them as assumptions rather than inventing them. -- When creating a visual or printable canvas, keep the same field structure as the - matching template. -- Do not reproduce branded poster/trade-dress artwork from source PDFs. Use the clean - bundled templates and preserve the operational structure. diff --git a/.claude/skills/business-model-design/assets/lean-business-model-canvas.html b/.claude/skills/business-model-design/assets/lean-business-model-canvas.html deleted file mode 100644 index f31ba43b..00000000 --- a/.claude/skills/business-model-design/assets/lean-business-model-canvas.html +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - Lean Business Model Canvas - - - -
-
-

Lean Business Model Canvas

-
Business / concept
{{BUSINESS_NAME}}
-
Date
{{DATE}}
-
Version
{{VERSION}}
-
-
-
-

Problem

-
Top 1-3 problems.
-
{{PROBLEM}}
-
-

Existing Alternatives

-
How these problems are solved today.
-
{{EXISTING_ALTERNATIVES}}
-
-
-
-

Solution

-
Possible solution for each problem.
-
{{SOLUTION}}
-
-
-

Unique Value Proposition

-
Single, clear reason to care and pay attention.
-
{{UNIQUE_VALUE_PROPOSITION}}
-
-

High-Level Concept

-
X-for-Y analogy or category shorthand.
-
{{HIGH_LEVEL_CONCEPT}}
-
-
-
-

Unfair Advantage

-
Something that cannot easily be bought or copied.
-
{{UNFAIR_ADVANTAGE}}
-
-
-

Customer Segments

-
Target customers and users.
-
{{CUSTOMER_SEGMENTS}}
-
-

Early Adopters

-
Characteristics of ideal first customers.
-
{{EARLY_ADOPTERS}}
-
-
-
-

Key Metrics

-
Numbers that show how the business is doing.
-
{{KEY_METRICS}}
-
-
-

Channels

-
Inbound or outbound path to customers.
-
{{CHANNELS}}
-
-
-

Cost Structure

-
Fixed and variable costs.
-
{{COST_STRUCTURE}}
-
-
-

Revenue Streams

-
Sources of revenue.
-
{{REVENUE_STREAMS}}
-
-
-
-
1. Problem
-
2. Customer Segments
-
3. Unique Value Proposition
-
4. Solution
-
5. Channels
-
6. Revenue Streams
-
7. Cost Structure
-
8. Key Metrics
-
9. Unfair Advantage
-
-
- - diff --git a/.claude/skills/business-model-design/assets/platform-business-model-canvas.html b/.claude/skills/business-model-design/assets/platform-business-model-canvas.html deleted file mode 100644 index 3bcd5e6c..00000000 --- a/.claude/skills/business-model-design/assets/platform-business-model-canvas.html +++ /dev/null @@ -1,254 +0,0 @@ - - - - - - Platform Business Model Canvas - - - -
-
- - - - - - -
Producers
-
Owner
-
Consumers
-
Partners
- -
Key Platform Components
-
Transactions
-
Value Propositions
- -
{{PRODUCERS}}
-
{{OWNER}}
-
{{CONSUMERS}}
-
{{PARTNERS}}
-
- - -
- - diff --git a/.claude/skills/business-model-design/assets/standard-business-model-canvas.html b/.claude/skills/business-model-design/assets/standard-business-model-canvas.html deleted file mode 100644 index 05399f2d..00000000 --- a/.claude/skills/business-model-design/assets/standard-business-model-canvas.html +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - Standard Business Model Canvas - - - -
-
-

Business Model Canvas

-
Designed for
{{DESIGNED_FOR}}
-
Designed by
{{DESIGNED_BY}}
-
Date
{{DATE}}
-
Version
{{VERSION}}
-
-
-
-

Key Partners

-
Partner network, suppliers, outsourced activities, and external dependencies.
-
{{KEY_PARTNERS}}
-
-
-

Key Activities

-
Most important activities required to make the model work.
-
{{KEY_ACTIVITIES}}
-
-
-

Value Propositions

-
The value offered to each customer segment.
-
{{VALUE_PROPOSITIONS}}
-
-
-

Customer Relationships

-
Relationship type expected by each segment.
-
{{CUSTOMER_RELATIONSHIPS}}
-
-
-

Customer Segments

-
Specific customers, users, buyers, and payers served.
-
{{CUSTOMER_SEGMENTS}}
-
-
-

Key Resources

-
Resources required by the value proposition, channels, relationships, and revenue model.
-
{{KEY_RESOURCES}}
-
-
-

Channels

-
How the organization reaches, sells to, delivers to, and supports each segment.
-
{{CHANNELS}}
-
-
-

Cost Structure

-
Main fixed and variable costs.
-
{{COST_STRUCTURE}}
-
-
-

Revenue Streams

-
Who pays, for what, how, when, and with what pricing model.
-
{{REVENUE_STREAMS}}
-
-
-
- - diff --git a/.claude/skills/business-model-design/references/business-model-output-rules.md b/.claude/skills/business-model-design/references/business-model-output-rules.md deleted file mode 100644 index 93dcb08e..00000000 --- a/.claude/skills/business-model-design/references/business-model-output-rules.md +++ /dev/null @@ -1,64 +0,0 @@ -# Business Model Output Rules - -## Compare Models - -When comparing two or more business models, compare on: - -- Customer/user/buyer/payer clarity. -- Value proposition strength. -- Channel access. -- Revenue quality: willingness to pay, recurrence, margin, collectability. -- Cost structure intensity. -- Key resource defensibility. -- Partner/dependency risk. -- Speed to evidence. -- Scalability and sustainability of the operating model. - -## Coherence Checks - -Every completed canvas should include: - -| Check | Question | -|---|---| -| Customer-problem fit | Does the value proposition solve a real problem for the stated segment? | -| Channel-model fit | Can the chosen channels reach the segment at an acceptable cost? | -| Revenue-value fit | Does the payer receive enough value to justify payment? | -| Activity-resource fit | Are activities and resources sufficient to deliver the promise? | -| Cost-revenue fit | Can gross margin, working capital, and scale economics work? | -| Partner-dependency fit | Are external dependencies acceptable or strategically dangerous? | - -## Validation Priorities - -Translate weak or unknown canvas fields into tests: - -- Problem: interview, observation, search/support evidence, willingness-to-switch test. -- Value proposition: landing page, concierge demo, concept test, paid pilot. -- Channel: outbound test, marketplace listing, referral test, sales-cycle discovery. -- Revenue: price test, budget-owner interview, paid pre-order, procurement discovery. -- Cost: delivery simulation, unit economics model, supplier quote. -- Platform: seed one side, liquidity test, trust/safety test, transaction completion test. - -## Output Format - -Default: - -```markdown -## Business Model Design: [Name] - -### Canvas Choice -[Chosen canvas] because [reason]. - -### Filled Canvas -[Canvas table] - -### Coherence Check -| Area | Assessment | Risk | -|---|---|---| - -### Validation Priorities -1. [Highest-risk assumption] -> [test] -2. [Next assumption] -> [test] - -### Next Decision -[What to decide next] -``` diff --git a/.claude/skills/business-model-design/references/canvas-selection.md b/.claude/skills/business-model-design/references/canvas-selection.md deleted file mode 100644 index e861018f..00000000 --- a/.claude/skills/business-model-design/references/canvas-selection.md +++ /dev/null @@ -1,27 +0,0 @@ -# Canvas Selection - -Use the canvas that matches the structure of the strategic question. - -| Situation | Use | Why | -|---|---|---| -| Existing company, product/service model, or mature venture | Standard Business Model Canvas | Captures value proposition, infrastructure, customer interface, cost, and revenue logic. | -| Early venture, corporate startup, new-to-world concept, or high uncertainty | Lean Business Model Canvas | Forces problem, alternatives, early adopters, unfair advantage, and key metrics into the model. | -| Marketplace, ecosystem, transaction platform, or multi-sided network | Platform Business Model Canvas | Separates stakeholder roles and value transactions across platform sides. | -| Sustainability redesign | Sustainable Business Model skill first, then Standard or Platform Canvas | Sustainability requires explicit social/environmental value logic before the operating model is finalized. | - -## Decision Questions - -Ask only what is needed: - -- Is there one customer group or several stakeholder groups exchanging value? -- Is this a known market or a high-uncertainty startup concept? -- Is the main question operating model, platform orchestration, or assumption validation? -- Does the business have separate user, buyer, payer, producer, consumer, owner, or partner roles? - -## Default Choice - -When unsure: - -1. Use Lean Business Model Canvas for new ventures. -2. Use Platform Business Model Canvas for multi-sided models. -3. Use Standard Business Model Canvas for everything else. diff --git a/.claude/skills/business-model-design/references/canvas-templates.md b/.claude/skills/business-model-design/references/canvas-templates.md deleted file mode 100644 index 0cc69e75..00000000 --- a/.claude/skills/business-model-design/references/canvas-templates.md +++ /dev/null @@ -1,203 +0,0 @@ -# Canvas Templates - -Use these exact operational field labels when producing blank or filled business model -artifacts. For visual or printable output, copy the matching file from `assets/` and -replace the `{{PLACEHOLDER}}` values. - -## Standard Business Model Canvas - -Use for a single-sided or conventional product/service business model. - -### Header Fields - -| Field | -|---| -| Designed for | -| Designed by | -| Date | -| Version | - -### Canvas Fields - -| Field | What To Fill | -|---|---| -| Key Partners | Partner network, suppliers, outsourced activities, external dependencies, and reasons for partnering. | -| Key Activities | The most important things the organization must do to make the model work. | -| Key Resources | Physical, intellectual, human, financial, data, brand, or network resources required by the model. | -| Value Propositions | The bundle of products, services, gains, or pain relief offered to each customer segment. | -| Customer Relationships | Relationship type expected by each segment: acquisition, retention, support, self-service, community, co-creation, or dedicated help. | -| Channels | How the organization reaches, sells to, delivers to, and supports each segment. | -| Customer Segments | Specific groups served; separate users, customers, buyers, and payers when they differ. | -| Cost Structure | Main fixed and variable costs created by resources, activities, partners, and channels. | -| Revenue Streams | Cash generated from each segment: what they pay for, how they pay, pricing mechanism, recurrence, and timing. | - -### Layout Rule - -Use this layout when preserving the canvas structure: - -```text -โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” -โ”‚ Key Partners โ”‚ Key โ”‚ Value โ”‚ Customer โ”‚ Customer โ”‚ -โ”‚ โ”‚ Activities โ”‚ Propositions โ”‚ Relationshipsโ”‚ Segments โ”‚ -โ”‚ โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค โ”‚ -โ”‚ โ”‚ Key โ”‚ โ”‚ Channels โ”‚ โ”‚ -โ”‚ โ”‚ Resources โ”‚ โ”‚ โ”‚ โ”‚ -โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค -โ”‚ Cost Structure โ”‚ Revenue Streams โ”‚ -โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ -``` - -### Editable Markdown Template - -| Key Partners | Key Activities | Value Propositions | Customer Relationships | Customer Segments | -|---|---|---|---|---| -| {{KEY_PARTNERS}} | {{KEY_ACTIVITIES}} | {{VALUE_PROPOSITIONS}} | {{CUSTOMER_RELATIONSHIPS}} | {{CUSTOMER_SEGMENTS}} | -| | **Key Resources**
{{KEY_RESOURCES}} | | **Channels**
{{CHANNELS}} | | -| **Cost Structure**
{{COST_STRUCTURE}} | | | **Revenue Streams**
{{REVENUE_STREAMS}} | | - -## Lean Business Model Canvas - -Use for early-stage ventures, corporate startups, and uncertain business concepts. - -### Header / Meta Fields - -| Field | -|---| -| Business / concept name | -| Date | -| Version | - -### Canvas Fields - -| Field | What To Fill | -|---|---| -| Problem | Top 1-3 customer problems or jobs. | -| Existing Alternatives | How these problems are solved today, including substitutes, workarounds, or non-consumption. | -| Solution | Possible solution for each problem. | -| Key Metrics | Numbers that show whether the business is working or learning. | -| Unique Value Proposition | Single, clear reason the target customer should care and pay attention. | -| High-Level Concept | Simple X-for-Y analogy or category shorthand. | -| Unfair Advantage | Something that cannot easily be bought or copied. | -| Channels | Inbound or outbound paths to customers. | -| Customer Segments | Target customers and users. | -| Early Adopters | Characteristics of the first ideal customers. | -| Cost Structure | Fixed and variable costs. | -| Revenue Streams | Sources of revenue. | - -### Fill Order - -Use this order when facilitating a blank canvas: - -1. Problem. -2. Customer Segments. -3. Unique Value Proposition. -4. Solution. -5. Channels. -6. Revenue Streams. -7. Cost Structure. -8. Key Metrics. -9. Unfair Advantage. - -`Existing Alternatives`, `High-Level Concept`, and `Early Adopters` are supporting -subfields attached to Problem, Unique Value Proposition, and Customer Segments. In -visual layouts they sit at the bottom of those tall columns without an internal -divider line. - -### Risk Lenses - -Use these risk lenses when turning the canvas into tests: - -| Risk Lens | Fields To Stress-Test | -|---|---| -| Product risk | Problem, Solution, Unique Value Proposition, Key Metrics. | -| Customer risk | Customer Segments, Early Adopters, Channels. | -| Market risk | Revenue Streams, Cost Structure, Existing Alternatives, Unfair Advantage. | - -### Layout Rule - -```text -โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” -โ”‚ Problem โ”‚ Solution โ”‚ Unique Value โ”‚ Unfair โ”‚ Customer โ”‚ -โ”‚ โ”‚ โ”‚ Proposition โ”‚ Advantage โ”‚ Segments โ”‚ -โ”‚ Existing โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค High-Level Concept โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค Early โ”‚ -โ”‚ Alternatives โ”‚ Key Metrics โ”‚ โ”‚ Channels โ”‚ Adopters โ”‚ -โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค -โ”‚ Cost Structure โ”‚ Revenue Streams โ”‚ -โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ -``` - -### Editable Markdown Template - -| Problem | Solution | Unique Value Proposition | Unfair Advantage | Customer Segments | -|---|---|---|---|---| -| {{PROBLEM}}

**Existing Alternatives**
{{EXISTING_ALTERNATIVES}} | {{SOLUTION}}

**Key Metrics**
{{KEY_METRICS}} | {{UNIQUE_VALUE_PROPOSITION}}

**High-Level Concept**
{{HIGH_LEVEL_CONCEPT}} | {{UNFAIR_ADVANTAGE}}

**Channels**
{{CHANNELS}} | {{CUSTOMER_SEGMENTS}}

**Early Adopters**
{{EARLY_ADOPTERS}} | -| **Cost Structure**
{{COST_STRUCTURE}} | | | **Revenue Streams**
{{REVENUE_STREAMS}} | | - -## Platform Business Model Canvas - -Use for platforms, marketplaces, ecosystems, and multi-sided business models. Preserve -the four stakeholder quadrants and central platform core. - -### Meta Fields - -| Field | -|---| -| Created by | -| Version / Date | -| Operation / Business Model | - -### Stakeholder Quadrants - -| Quadrant | What To Fill | -|---|---| -| Producers | Stakeholders who create, supply, list, publish, sell, or contribute value through the platform. | -| Owner | Actor or organization that governs, operates, monetizes, and evolves the platform. | -| Consumers | Stakeholders who consume, buy, use, discover, or benefit from producer-side value. | -| Partners | Complementors, infrastructure providers, distributors, regulators, or ecosystem allies. | - -### Platform Core Fields - -| Field | What To Fill | -|---|---| -| Key Platform Components | The enabling components that make exchange possible: matching, identity, trust, reputation, payment, rules, APIs, data, discovery, logistics, moderation, analytics, or other core modules. | -| Value Transactions | Exchanges between stakeholder groups: money, data, goods, services, attention, trust, reputation, access, knowledge, or risk transfer. | -| Value Propositions | Specific reasons each stakeholder group participates. | - -### Layout Rule - -```text -โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” -โ”‚ Producers โ”‚ Owner โ”‚ -โ”‚ โ”‚ โ”‚ -โ”‚ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”‚ -โ”‚ โ”‚ Key Platform Components โ”‚ โ”‚ -โ”‚ โ”‚ Value Transactions โ”‚ โ”‚ -โ”‚ โ”‚ Value Propositions โ”‚ โ”‚ -โ”‚ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ”‚ -โ”‚ โ”‚ โ”‚ -โ”‚ Consumers โ”‚ Partners โ”‚ -โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ - -Side panel: Created by, Version / Date, Operation / Business Model, and canvas title. -``` - -### Editable Markdown Template - -| Platform Stakeholders | Filled Content | -|---|---| -| Producers | {{PRODUCERS}} | -| Owner | {{OWNER}} | -| Consumers | {{CONSUMERS}} | -| Partners | {{PARTNERS}} | - -| Platform Core | Filled Content | -|---|---| -| Key Platform Components | {{KEY_PLATFORM_COMPONENTS}} | -| Value Transactions | {{VALUE_TRANSACTIONS}} | -| Value Propositions | {{VALUE_PROPOSITIONS}} | - -| Meta | Filled Content | -|---|---| -| Created by | {{CREATED_BY}} | -| Version / Date | {{VERSION_DATE}} | -| Operation / Business Model | {{OPERATION_DESCRIPTION}} | diff --git a/.claude/skills/business-model-design/references/pm-skills-main-merge.md b/.claude/skills/business-model-design/references/pm-skills-main-merge.md deleted file mode 100644 index d4791598..00000000 --- a/.claude/skills/business-model-design/references/pm-skills-main-merge.md +++ /dev/null @@ -1,140 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to strengthen Business Model Canvas coverage and mode switching between BMC, Lean Canvas, Startup Canvas, and Value Proposition views. - -## Routing Signals - -- business model canvas -- bmc -- all modes -- value proposition mode - -## pm-product-strategy/skills/business-model/SKILL.md - -## Metadata -- **Name**: business-model -- **Description**: Generate a Business Model Canvas with all 9 building blocks. Use when creating a business model, documenting how a business creates value, or analyzing an existing business model. -- **Triggers**: business model canvas, BMC, business model, how we make money - -## Instructions - -You are a business model strategist designing a Business Model Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Business Model Canvas that outlines how the business creates, delivers, and captures value. - -## Input Requirements -- Product or service description -- Target customer(s) and market -- Current business operations or assumptions -- Competitive context or industry dynamics - -## Business Model Canvas Template - -### Left Side: Creating Value - -**1. Key Partners** -- Who are the key strategic partners and suppliers? -- What partnerships enable our business model? -- Which activities do partners handle? -- Are there joint ventures or co-creation opportunities? - -**2. Key Activities** -- What key activities does the business perform? -- What processes are critical to delivering value? -- Are these activities in-house or outsourced? -- Production, problem-solving, platform/network activities? - -**3. Key Resources** -- What resources are necessary to create value? -- Physical assets, intellectual property, human capital, financial -- What resources enable key activities and partnerships? -- What's the minimum viable resource set? - -### Center: The Value Proposition - -**4. Value Propositions** -- What value do we deliver to customers? -- Which customer problems do we solve? -- What needs are satisfied? -- What products/services address each segment? -- Quantitative (price, speed, quality) vs. qualitative (design, status) - -### Right Side: Delivering Value - -**5. Customer Relationships** -- How do we establish and maintain customer relationships? -- Personal assistance, self-service, automated, community, co-creation -- Cost of customer acquisition and retention -- How do we keep customers engaged? - -**6. Channels** -- How do customers discover and access the value? -- Awareness: How do customers learn about us? -- Purchase: How do they buy? -- Delivery: How is value delivered? -- After-sales: How do we support customers? -- Direct vs. indirect, owned vs. partner channels - -**7. Customer Segments** -- Who are the key customer segments? -- Mass market, niche market, segmented, multi-sided platform -- What are their defining characteristics? -- Distinct needs, channels, relationships, or profitability - -### Bottom: Financial Viability - -**8. Cost Structure** -- What are the most important costs? -- Fixed vs. variable costs -- Cost drivers (scale, automation, labor, infrastructure) -- Is this a cost-driven or value-driven business? - -**9. Revenue Streams** -- How does the business make money? -- Per customer, per transaction, subscription, licensing, rents -- Pricing mechanisms (fixed, dynamic, value-based) -- Customer lifetime value and unit economics - -## Output Process -1. Identify and profile customer segments -2. Define the core value proposition(s) -3. Map customer relationships and channels -4. List key activities and resources -5. Identify key partners -6. Outline cost structure -7. Define revenue streams -8. Ensure all 9 blocks align and support each other -9. Test economic viability (LTV > 3x CAC) -10. Identify key assumptions and risks - -### Domain Context - -**Business Model Canvas vs Lean Canvas vs Startup Canvas**: - -Business Model Canvas (Strategyzer, Alexander Osterwalder) is the most widely used canvas framework. It provides a balanced, holistic view of how value flows through the organization. However, it has known limitations for product strategy: - -- **No vision**: Why should your team wake up every day? BMC doesn't address motivation or aspiration. -- **No Can't/Won't test**: What stops competitors from copying you? BMC lacks a defensibility section that goes beyond listing resources. -- **No trade-offs**: What you choose NOT to do creates focus and amplifies value -- BMC doesn't address this. -- **No key metrics**: How do you know the strategy is working? BMC has no metrics section. -- **Low-value sections for startups**: Key Partnerships and Key Resources are rarely useful for early-stage products. - -**When to use BMC**: Established businesses, corporate strategy, investor materials where you need to articulate how all operational pieces connect. - -**Alternatives**: -- **Lean Canvas** (Ash Maurya): Startup-focused, faster, replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. Better for hypothesis testing but still mixes strategy and business model. -- **Startup Canvas** (Pawe Huryn): Separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended for new products where you need strategic clarity alongside the business model. - -## Notes -- The Business Model Canvas provides a holistic view of how value flows through the organization -- Each block should reinforce and support the others -- Strong business models have clear, defensible value propositions -- Financial sustainability requires revenue to exceed costs at scale -- Use this to identify opportunities for innovation and optimization - ---- - -### Further Reading - -- [Business Model Canvas Examples: Google Maps, Airbnb, Uber](https://www.productcompass.pm/p/business-model-canvas-examples) -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) diff --git a/.claude/skills/business-strategy-creation-from-expert-strategic-thinking/SKILL.md b/.claude/skills/business-strategy-creation-from-expert-strategic-thinking/SKILL.md deleted file mode 100644 index 80cba85a..00000000 --- a/.claude/skills/business-strategy-creation-from-expert-strategic-thinking/SKILL.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -name: business-strategy-creation-from-expert-strategic-thinking -description: >- - Business strategy creation from expert strategic thinking. Use when the user needs a product - workflow for product strategy related to business strategy creation from expert strategic - thinking. Trigger terms: strategy, decision-making, business, leadership. ---- - - - -# Business strategy creation from expert strategic thinking - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `business-strategy-creation-from-expert-strategic-thinking` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Business strategy creation from expert strategic thinking strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Business strategy creation from expert strategic thinking**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Business strategy creation from expert strategic thinking. -Success metric: -- Provides crisp, actionable strategic guidance tailored to the user's input. -- Either asks targeted clarifying questions or delivers a structured strategy response. -- Keeps advice grounded in SWOT and coherent strategic logic. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUT}}`; if context is insufficient, ask targeted questions first. -- Keep responses concise, direct, and free of hype or AI references. -- Ground guidance in strengths, weaknesses, opportunities, and threats. -- Provide coherent strategy logic with concrete next steps and priorities. -- If providing a plan, include short-term and long-term goals plus momentum flywheels. - -FORMAT -Return exactly this structure: - -Your message here - -FAILURE -- `` wrapper is missing or malformed. -- Response is overly verbose, abstract, or generic. -- Guidance ignores SWOT or lacks concrete priorities/actions. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/capital-structure-financing/SKILL.md b/.claude/skills/capital-structure-financing/SKILL.md deleted file mode 100644 index 393dc7e3..00000000 --- a/.claude/skills/capital-structure-financing/SKILL.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -name: capital-structure-financing -description: >- - Productize Finance engine for debt versus equity financing, leverage, enterprise value, - equity value, WACC, APV, tax shields, bonds, credit spreads, IPOs, SEOs, covenants, - warrants, and financing side effects. ---- - - - -# Capital Structure Financing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `capital-structure-financing` -- **Lifecycle**: Strategize -- **Category**: Finance -- **Primary artifact**: Capital-structure and financing analysis with EV/equity bridge, leverage, WACC/APV logic, financing side effects, and warnings - -## Purpose - -Financing and capital-structure skill. Use it to compare debt versus equity financing, -model leverage, estimate WACC, perform APV valuation, value bonds, analyze tax -shields, and connect financing decisions to firm value. - -## Core Formulas - -- `Assets = Liabilities + Equity` -- `Enterprise Value = Equity + Debt + Preferred Stock + Noncontrolling Interest - Cash - Nonoperating Assets` -- `Equity Value = Enterprise Value - Net Debt` -- `Debt-to-Equity = D / E` -- `Debt-to-Value = D / (D + E)` -- `DFL = EBIT / (EBIT - Interest)` -- `WACC = E/(D+E) * r_E + D/(D+E) * (1 - T_c) * r_D` -- `V_L = V_U + PV(Tax Shields)` -- `PV(Tax Shields) = T_c * D` for fixed perpetual debt discounted at cost of debt. -- `APV = NPV_unlevered + PV(Tax Shields) - PV(Expected Distress Costs) - Issuance Costs` -- `Bond Price = sum(Coupon_t / (1 + y)^t) + Face Value / (1 + y)^N` -- `Credit Spread = Yield on Risky Debt - Matched Risk-Free Yield` - -## Financing Instruments - -Common stock, preferred stock, warrants, bank loans, revolving credit lines, term -loans, corporate bonds, convertible debt, senior debt, subordinated debt, IPOs, and -SEOs. - -## Required Validation - -- Use market values for WACC weights. -- Warn if company WACC is applied to a different-risk project. -- Warn if debt is assumed risk-free when credit risk is material. -- Warn if tax shields are counted twice. -- Warn if financing cash flows are included in FCF and WACC also includes financing. -- Warn if APV and WACC assumptions are mixed incorrectly. -- Use APV when debt follows a fixed schedule. -- Use WACC when the firm maintains a target leverage ratio. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. State whether the analysis is WACC-consistent or APV-consistent. diff --git a/.claude/skills/challenging-meeting-with-stakeholders/SKILL.md b/.claude/skills/challenging-meeting-with-stakeholders/SKILL.md deleted file mode 100644 index 3615436a..00000000 --- a/.claude/skills/challenging-meeting-with-stakeholders/SKILL.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -name: challenging-meeting-with-stakeholders -description: >- - Challenging meeting with stakeholders. Use when the user needs a product workflow for - stakeholder management related to challenging meeting with stakeholders. Trigger terms: - stakeholders, meeting-prep, risk-management. ---- - - - -# Challenging meeting with stakeholders - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `challenging-meeting-with-stakeholders` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Challenging meeting with stakeholders stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Challenging meeting with stakeholders**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{GOAL_OR_CONTEXT}} -- {{STAKEHOLDERS}} - - -GOAL -Produce a high-quality deliverable for: Challenging meeting with stakeholders. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate at least 20 challenging stakeholder questions based on `{{GOAL_OR_CONTEXT}}` and `{{STAKEHOLDERS}}`. -- Cover financials, resources, timeline, risks, market, competition, feasibility, UX, ethics, sustainability, team capability, past performance, strategy alignment, compliance, and scalability. -- Make questions rigorous and probing; avoid generic filler. - -FORMAT -Return exactly this structure: - - -1. [First question] -2. [Second question] -3. [Third question] -... - - -FAILURE -- `` is missing, malformed, or has fewer than 20 questions. -- Questions are generic, repetitive, or not tied to the provided context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/churn-reduction-from-customer-data-and-exit-survey-analysis/SKILL.md b/.claude/skills/churn-reduction-from-customer-data-and-exit-survey-analysis/SKILL.md deleted file mode 100644 index 7430ce0f..00000000 --- a/.claude/skills/churn-reduction-from-customer-data-and-exit-survey-analysis/SKILL.md +++ /dev/null @@ -1,160 +0,0 @@ ---- -name: churn-reduction-from-customer-data-and-exit-survey-analysis -description: >- - Churn reduction from customer data and exit survey analysis. Use when the user needs a - product workflow for business analysis related to churn reduction from customer data and - exit survey analysis. Trigger terms: pm, business-analysis, churn, retention, analytics. ---- - - - -# Churn reduction from customer data and exit survey analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `churn-reduction-from-customer-data-and-exit-survey-analysis` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Churn diagnosis with retention levers, experiments, and follow-up research - -Use this skill to run the Productize prompt contract for **Churn reduction from customer data and exit survey analysis**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CHURN_DATA}} -- {{EXIT_SURVEY_RESPONSES}} -- {{ACTIVE_CUSTOMERS_BY_PERIOD_COHORT}} - - -GOAL -Produce a high-quality deliverable for: Churn reduction from customer data and exit survey analysis. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Use only evidence from `CHURN_DATA`, `EXIT_SURVEY_RESPONSES`, and `ACTIVE_CUSTOMERS_BY_PERIOD_COHORT`; if data is missing, state assumptions explicitly. -- Use these metric definitions: - - Customer churn rate = `churned_customers_in_period / active_customers_start`. - - MRR churn rate = `churned_mrr_in_period_usd / active_mrr_start_usd`. - - "Average customer lifetime" must be labeled as `churned-user tenure proxy` unless full customer lifecycle data is provided. -- Compute churn rate using denominator data from `ACTIVE_CUSTOMERS_BY_PERIOD_COHORT`; include overall and cohort-level rates when possible. -- If denominator data is insufficient for any requested slice, state "not computable for this slice" and use explicit proxy metrics (churn events, churned MRR) for that slice. -- Analyze both quantitative patterns (rate, lifetime, segment/time trends) and qualitative churn reasons (theme categories from exits). -- Prioritize interventions by estimated impact x feasibility. -- Include short-term (0-30 days), medium-term (31-90 days), and long-term (90+ days) actions. -- Every recommendation must trace to a specific churn reason or segment pattern. -- For each prioritized key insight, provide at least one specific strategy. -- If churned-user sample counts in `CHURN_DATA`/`EXIT_SURVEY_RESPONSES` differ from denominator totals in `ACTIVE_CUSTOMERS_BY_PERIOD_COHORT`, explicitly disclose the mismatch and treat sample-derived insights as directional. -- Do not add impact estimates from overlapping cohorts (e.g., `incident_exposed` and `price_change_seen`) as if independent; call out overlap risk. -- Do not give generic advice without a data link. - - -FORMAT -Return exactly this structure: - - -1. Data Analysis Summary -- Current churn rate (overall + by key period/cohort), churned-user tenure proxy, and relevant baseline metrics -- Denominator coverage check (which churn rates are computable vs not computable) -- Sample alignment check (sample sizes, coverage, and mismatch disclosure if present) -- Churned-user profile patterns (segments, behavior, timing) -- Exit-survey theme breakdown with frequency or relative weight - -2. Key Insights (3-5, prioritized) -- Insight title -- Evidence (data points/themes supporting it) -- Why it matters for churn reduction - -3. Targeted Strategies -- Linked insight: -- Issue to solve: -- Action plan: -- Time horizon: Short-term | Medium-term | Long-term -- Owner suggestion: -- Success metrics (leading + lagging): -- Expected effect on churn: - -4. Monitoring and Adjustment -- Review cadence -- Instrumentation and dashboard checks -- Decision rules for doubling down, iterating, or stopping actions - -5. Expected Impact -- Estimated churn reduction range using scenario bands: Conservative | Base | Aggressive -- Time to observe impact -- Key assumptions and risks - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/clustered-jtbd-forces-from-interview-data/SKILL.md b/.claude/skills/clustered-jtbd-forces-from-interview-data/SKILL.md deleted file mode 100644 index d6453e5c..00000000 --- a/.claude/skills/clustered-jtbd-forces-from-interview-data/SKILL.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -name: clustered-jtbd-forces-from-interview-data -description: >- - Clustered JTBD forces from interview data. Use when the user needs a product workflow for - user research related to clustered jtbd forces from interview data. Trigger terms: - user-research, jtbd, interviews. ---- - - - -# Clustered JTBD forces from interview data - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `clustered-jtbd-forces-from-interview-data` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Clustered JTBD forces from interview data research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Clustered JTBD forces from interview data**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INTERVIEW_DATA}} -- {{FORCE_TYPE}} - - -GOAL -Produce a high-quality deliverable for: Clustered JTBD forces from interview data. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{INTERVIEW_DATA}}` to code and affinitize only the specified JTBD force type `{{FORCE_TYPE}}`. -- Conceptually construct a binary coding matrix: -- Stories as rows. -- Force concepts as columns. -- Existing concept match -> code `1`. -- Novel concept -> add new column and backfill prior rows with `0`. -- Abstract and stabilize force columns with overarching labels. -- Identify stories that introduce unique force concepts. -- Summarize structure, categories, unique contributors, and notable clustering patterns. -- Keep scope strictly to the selected force type and explicitly state assumptions if input structure is incomplete. - -FORMAT -Return exactly this structure: - - -1. Spreadsheet Summary: - [Provide a brief overview of the spreadsheet structure] - -2. Force Categories: - [List the abstract labels for each force column] - -3. Unique Force Contributors: - [List the stories that introduced unique forces] - -4. Insights and Patterns: - [Share any notable observations from the affinitizing process] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Output mixes in non-selected force types or unsupported assumptions. -- Force categories are not abstracted/stabilized or unique contributors are missing. -- Insights do not reflect coding/affinity patterns from the provided data. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/cohort-analysis/SKILL.md b/.claude/skills/cohort-analysis/SKILL.md deleted file mode 100644 index a4b47e93..00000000 --- a/.claude/skills/cohort-analysis/SKILL.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -name: cohort-analysis -description: >- - Cohort Analysis. Use when analyzing retention by signup, activation, usage, plan, feature - adoption, or customer segment, especially when churn, engagement, or product health needs - cohort evidence. ---- - - - -# Cohort Analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `cohort-analysis` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Cohort retention and engagement diagnosis with segment-level actions - -Use when analyzing retention by signup, activation, usage, plan, feature adoption, or customer segment, especially when churn, engagement, or product health needs cohort evidence. - -## Productize Contract - -- **Primary lifecycle**: Measure -- **Supporting lifecycle**: Growth -- **Primary artifact**: Cohort retention and engagement diagnosis with segment-level actions -- **Source method**: pm-skills-main/pm-data-analytics/skills/cohort-analysis/SKILL.md - -## Method - -## Purpose -Analyze user engagement and retention patterns by cohort to identify trends in user behavior, feature adoption, and long-term engagement. Combine quantitative insights with qualitative research recommendations. - -## How It Works - -### Step 1: Read and Validate Your Data -- Accept CSV, Excel, or JSON data files with user cohort information -- Verify data structure: cohort identifier, time periods, engagement metrics -- Check for missing values and data quality issues -- Summarize key statistics (cohort sizes, date ranges, metrics available) - -### Step 2: Generate Quantitative Analysis -- Calculate cohort retention rates and engagement trends -- Identify retention curves, drop-off patterns, and anomalies -- Compute feature adoption rates across cohorts -- Calculate month-over-month or period-over-period changes -- Generate Python analysis scripts using pandas and numpy if requested - -### Step 3: Create Visualizations -- Generate retention heatmaps (cohorts vs. time periods) -- Create line charts showing cohort progression -- Build comparison charts for feature adoption -- Visualize drop-off points and engagement trends -- Output as interactive charts or static images - -### Step 4: Identify Insights & Patterns -- Spot one or more significant patterns: - - Early churn in specific cohorts - - Late-stage engagement changes - - Feature adoption clusters - - Seasonal or temporal trends -- Highlight surprising findings and deviations -- Compare cohort performance to establish baselines - -### Step 5: Suggest Follow-Up Research -- Recommend qualitative research methods: - - Targeted user interviews with churning users - - Feature usage surveys with engaged cohorts - - Session replays of key interaction patterns - - Win/loss analysis for high vs. low retention cohorts -- Design follow-up quantitative studies -- Suggest A/B tests or feature experiments - -## Usage Examples - -**Example 1: Upload CSV Data** -``` -Upload cohort_engagement.csv with columns: cohort_month, weeks_active, -user_id, feature_x_usage, engagement_score - -Request: "Analyze retention patterns and identify why Q4 2025 cohorts -underperform compared to Q3" -``` - -**Example 2: Describe Data Format** -``` -"I have monthly user cohorts from Jan-Dec 2025. Each row shows: -cohort date, user ID, purchase frequency, and support tickets. -Analyze which cohorts show best long-term retention." -``` - -**Example 3: Feature Adoption Analysis** -``` -Upload feature_usage.xlsx with cohort adoption data. - -Request: "Compare adoption curves for our new feature across cohorts. -Which cohorts adopted fastest? Any patterns?" -``` - -## Key Capabilities - -- **Data Reading**: Import CSV, Excel, JSON, SQL query results -- **Retention Analysis**: Calculate and visualize retention rates over time -- **Cohort Comparison**: Compare metrics across cohort groups -- **Anomaly Detection**: Flag unusual patterns or drop-offs -- **Python Scripts**: Generate reusable analysis code for ongoing analysis -- **Visualizations**: Create heatmaps, charts, and interactive dashboards -- **Research Design**: Suggest targeted follow-up studies and interview approaches -- **Statistical Summary**: Provide quantitative metrics and correlation analysis - -## Tips for Best Results - -1. **Include time dimension**: Provide data across multiple time periods -2. **Define cohort clearly**: Make cohort grouping explicit (signup month, feature launch date, etc.) -3. **Provide context**: Explain product changes, launches, or events during the period -4. **Multiple metrics**: Include retention, engagement, feature usage, revenue, etc. -5. **Sufficient data**: At least 3-4 cohorts for meaningful pattern identification -6. **Request specific output**: Ask for visualizations, Python scripts, or research recommendations - -## Output Format - -You'll receive: -- **Data Summary**: Cohort overview and data quality assessment -- **Quantitative Findings**: Key metrics, retention rates, and trend analysis -- **Visualizations**: Charts showing retention curves, adoption patterns -- **Pattern Identification**: 2-3 significant insights from the data -- **Research Recommendations**: Specific qualitative and quantitative follow-ups -- **Analysis Scripts** (if requested): Python code for reproducible analysis -- **Next Steps**: Prioritized actions based on findings - ---- - -### Further Reading - -- [Cohort Analysis 101: How to Reduce Churn and Make Better Product Decisions](https://www.productcompass.pm/p/cohort-analysis) -- [The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs](https://www.productcompass.pm/p/the-product-analytics-playbook-aarrr) -- [Are You Tracking the Right Metrics?](https://www.productcompass.pm/p/are-you-tracking-the-right-metrics) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/comms-review/SKILL.md b/.claude/skills/comms-review/SKILL.md deleted file mode 100644 index 411e5ab8..00000000 --- a/.claude/skills/comms-review/SKILL.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -name: comms-review -description: >- - Communications gate for stakeholder narrative, executive updates, customer announcements, - launch messaging, risk framing, asks, and alignment moments. Use before external-facing or - leadership-facing product communication. ---- - - - -# Comms Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `comms-review` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Comms review with audience map, message readout, misalignment risks, decision, and handoff - -Use this gate when product work needs to be understood, approved, adopted, or acted -on by people outside the immediate build loop. - -## Artifact Format - -Use Markdown for short update copy. Use self-contained HTML when the communication -artifact needs audience-specific tabs, proof-point tables, risk framing, launch -message variants, executive-friendly visuals, or a shareable stakeholder explainer. - -## Route Internally - -- `$stakeholder-update` -- `$executive-and-update-review` -- `$message-framing-and-comms-plan-designer` -- `$presentations-from-structured-content-and-context` -- `$slide-decks-from-problem-statements-and-context` -- `$demo-narratives-showing-user-goals` -- `$release-notes` - -## Required Output - -Return: - -1. **Audience Map**: audience, decision, concern, desired action, and evidence standard. -2. **Message Readout**: narrative, value, risks, tradeoffs, asks, and proof points. -3. **Misalignment Risks**: likely objections, confusion, missing context, and sensitive claims. -4. **Decision**: approve, revise, split audiences, delay, or escalate. -5. **Handoff**: release, docs, product, thesis, or growth follow-up. diff --git a/.claude/skills/competitive-advantage-diagnostics-and-moat-strategy/SKILL.md b/.claude/skills/competitive-advantage-diagnostics-and-moat-strategy/SKILL.md deleted file mode 100644 index 91f01ef8..00000000 --- a/.claude/skills/competitive-advantage-diagnostics-and-moat-strategy/SKILL.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -name: competitive-advantage-diagnostics-and-moat-strategy -description: >- - Competitive Advantage Diagnostics and Moat Strategy. Use when the user needs a product - workflow for product strategy related to competitive advantage diagnostics and moat - strategy. Trigger terms: strategy, competitive-advantage, moats, 7-powers. ---- - - - -# Competitive Advantage Diagnostics and Moat Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `competitive-advantage-diagnostics-and-moat-strategy` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Competitive Advantage Diagnostics and Moat Strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Competitive Advantage Diagnostics and Moat Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{BUSINESS_NAME}} -- {{ONE_LINER}} -- {{STAGE}} -- {{BUSINESS_MODEL}} -- {{UNIT_ECONOMICS}} -- {{SCALE}} -- {{PRODUCT_USAGE}} -- {{DATA_IP_RESOURCES}} -- {{GTM}} -- {{COMPETITION}} -- {{CONSTRAINTS}} -- {{TIME_HORIZON}} - - -GOAL -Produce a high-quality deliverable for: Competitive Advantage Diagnostics and Moat Strategy. -Success metric: -- Diagnoses which of the 7 Powers are present, emerging, or absent with evidence-linked benefits and barriers. -- Provides acquisition playbooks for missing powers with concrete steps and KPIs. -- Produces a prioritized 30/60/90 plan and red-team risks with validation tests. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if key inputs are missing, state assumptions explicitly (do not ask questions in the output). -- For every claimed advantage, pair benefit + barrier; no barrier means no Power. -- Diagnose each of the 7 Powers as Present/Emerging/Absent with evidence and confidence. -- Provide acquisition playbooks for each Absent/Emerging power with concrete actions and KPIs. -- Include 30/60/90 actions and a red-team section with falsification tests. -- Keep claims specific, measurable, and grounded in inputs. - -FORMAT -Return exactly this structure: - -### A) Summary Table - -| Power | Status (Present/Emerging/Absent) | Benefit | Barrier | Evidence & Metrics | Confidence | Trend (โ†‘/โ†’/โ†“) | Stage Fit | -| ----- | -------------------------------- | ------- | ------- | ------------------ | ---------: | :-----------: | --------- | - -### B) Verdict (<=120 words) - -[Plain-English call on sustainability of advantage.] - -### C) Acquisition Playbooks (for each Absent/Emerging power) - -**[Power Name]** -- Prerequisites: [List] -- Plays (3-5): [Concrete steps] -- 12-24 mo roadmap: [Milestones] -- KPIs & leading indicators: [Metrics + targets] -- Risks & countermeasures: [Bullets] -- Stop/kill criteria: [Bullets] - -### D) 30/60/90 - -- 30 days: [Top 3 actions with owner, resources, success metric] -- 60 days: [Top 3 actions with owner, resources, success metric] -- 90 days: [Top 3 actions with owner, resources, success metric] - -### E) Red Team - -1. [Why this could be wrong] - [How to test] -2. [Why this could be wrong] - [How to test] -3. [Why this could be wrong] - [How to test] - -FAILURE -- Any required section/table from `FORMAT` is missing, malformed, or incomplete. -- Any power marked Present/Emerging lacks a clear benefit+barrier pairing. -- Acquisition playbooks are missing for any Absent/Emerging power. -- 30/60/90 actions lack owners, resources, or success metrics. -- Red-team section lacks falsification tests. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/competitive-analysis-to-winning-positioning-strategy/SKILL.md b/.claude/skills/competitive-analysis-to-winning-positioning-strategy/SKILL.md deleted file mode 100644 index 56f9b19c..00000000 --- a/.claude/skills/competitive-analysis-to-winning-positioning-strategy/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: competitive-analysis-to-winning-positioning-strategy -description: >- - Competitive analysis to winning positioning strategy. Use when the user needs a product - workflow for product strategy related to competitive analysis to winning positioning - strategy. Trigger terms: positioning, competition, product-marketing, differentiation. ---- - - - -# Competitive analysis to winning positioning strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `competitive-analysis-to-winning-positioning-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Competitive analysis to winning positioning strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Competitive analysis to winning positioning strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPETITIVE_ANALYSIS}} - - -GOAL -Produce a high-quality deliverable for: Competitive analysis to winning positioning strategy. -Success metric: -- Produces a data-backed positioning strategy grounded in competitive analysis. -- Identifies 3โ€“5 clear differentiators with customer-relevant rationale. -- Outputs a concise, compelling value proposition and the reasoning behind it. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPETITIVE_ANALYSIS}}`; if data is missing, state assumptions explicitly. -- Identify 3โ€“5 differentiators grounded in the competitive analysis. -- For each differentiator, explain customer value and competitive significance. -- Define a clear target audience and market position based on evidence. -- Value proposition must answer โ€œwhy choose usโ€ without introducing unsupported claims. - -FORMAT -Return exactly this structure: - - -1. [Differentiator] - [Why it matters to customers] - [Evidence from analysis] -2. [Differentiator] - [Why it matters to customers] - [Evidence from analysis] -3. [Differentiator] - [Why it matters to customers] - [Evidence from analysis] -[Optional 4th/5th differentiator] - - - -[Target audience, market position, and how differentiators map to customer needs and gaps] - - - -[Concise statement answering why choose us] - - - -[Explain reasoning with explicit references to competitive analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 or more than 5 differentiators are provided. -- Positioning or value proposition is not grounded in provided analysis. -- Rationale lacks evidence references. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/competitive-brief/SKILL.md b/.claude/skills/competitive-brief/SKILL.md deleted file mode 100644 index 7dc4ff34..00000000 --- a/.claude/skills/competitive-brief/SKILL.md +++ /dev/null @@ -1,446 +0,0 @@ ---- -name: competitive-brief -description: >- - Create a competitive analysis brief for one or more competitors or a feature area. Use when - informing product strategy or feature prioritization, building sales battle cards, prepping - board or investor materials, or deciding where to differentiate versus achieve parity. ---- - - - -# Competitive Brief - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `competitive-brief` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Competitive Brief strategy memo with choices, tradeoffs, risks, and recommended next move - -Create a competitive analysis brief for one or more competitors or a feature area. - -## Argument Hint - -`` - -## Usage - -```text -/competitive-brief $ARGUMENTS -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `competitive battlecard`, `sales battlecard`, `objection handling`, `win loss`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Scope the Analysis - -Ask the user: -- **Competitor(s)**: Which specific competitor(s) to analyze? Or a feature area to compare across competitors? -- **Focus**: Full product comparison, specific feature area, pricing/packaging, go-to-market, or positioning? -- **Context**: What decision will this inform? Product strategy, sales enablement, investor/board materials, or feature prioritization? - -### 2. Research - -Use web research when available: -- Product pages and feature lists -- Pricing pages and packaging -- Recent product launches, blog posts, and changelogs -- Press coverage and analyst reports -- Customer reviews and ratings from G2, Capterra, TrustRadius, or similar sources -- Job postings as signals of strategic direction -- Social media and community discussions - -If a knowledge base is connected: -- Search for existing competitive analysis documents -- Find win/loss reports or sales battle cards -- Pull prior competitive research - -If chat is connected: -- Search for competitive mentions in sales or product channels -- Find recent deal feedback involving competitors - -### 3. Generate the Brief - -#### Competitor Overview - -For each competitor: -- Company summary: founding, size, funding/revenue if public, target market -- Product positioning: how they describe themselves, who they target -- Recent momentum: launches, funding, partnerships, customer wins - -#### Feature Comparison - -Compare capabilities across key areas relevant to the analysis. Use the feature comparison matrix guidance below for rating scales and templates. - -#### Positioning Analysis - -Analyze how each competitor positions themselves: target customer, category claim, key differentiator, and value proposition. Use the positioning statement template and message architecture levels below. - -#### Strengths and Weaknesses - -For each competitor: -- **Strengths**: Where they genuinely excel. What customers praise. -- **Weaknesses**: Where they fall short. What customers complain about. -- Be honest and evidence-based. Do not dismiss competitors or inflate their weaknesses. - -#### Opportunities - -Based on the analysis: -- Where are there gaps in competitor offerings we could exploit? -- What are customers asking for that no one provides well? -- Where are competitors making bets we disagree with? -- What market shifts could advantage our approach? - -#### Threats - -- Where are competitors investing heavily? -- What competitive moves could disrupt our position? -- Where are we most vulnerable? -- What would a nightmare-scenario competitive move look like? - -#### Strategic Implications - -Tie the analysis back to product strategy: -- What should we build, accelerate, or deprioritize based on this analysis? -- Where should we differentiate versus achieve parity? -- How should we adjust positioning or messaging? -- What should we monitor going forward? - -### 4. Follow Up - -After generating the brief: -- Ask if the user wants to dive deeper on any section -- Offer to create a one-page summary for executives -- Offer to create sales battle cards for competitive deals -- Offer to draft a "how to win against [competitor]" guide -- Offer to set up a monitoring plan for competitive moves - -## Competitive Landscape Mapping - -### Identifying the Competitive Set - -Define competitors at multiple levels: - -**Direct competitors**: Products that solve the same problem for the same users in the same way. -- These are the products your customers actively evaluate against you. -- They appear in deals, customer comparisons, and review-site matchups. - -**Indirect competitors**: Products that solve the same problem differently. -- Different approach to the same user need, such as spreadsheets versus a dedicated project management tool. -- Include non-consumption: sometimes the competitor is doing nothing or using a manual process. - -**Adjacent competitors**: Products that do not compete today but could. -- Companies with similar technology, customer base, or distribution that could expand into your space. -- Larger platforms that could add your functionality as a feature. -- Startups attacking a niche that could grow into your core market. - -**Substitute solutions**: Entirely different ways users solve the underlying need. -- Hiring a person instead of buying software. -- Using a general-purpose tool such as Excel or email instead of a specialized one. -- Outsourcing the process entirely. - -### Landscape Map - -Position competitors on meaningful dimensions: - -Common axes: -- Breadth versus depth: suite versus point solution -- SMB versus enterprise: market segment focus -- Self-serve versus sales-led: go-to-market approach -- Simple versus powerful: product complexity -- Horizontal versus vertical: general purpose versus industry-specific - -Choose axes that reveal strategic positioning differences relevant to your market. The right axes make competitive dynamics visible. - -### Monitoring the Landscape - -Track competitive movements over time: -- Product launches and feature releases: changelogs, blog posts, press releases -- Pricing and packaging changes -- Funding rounds and acquisitions -- Key hires and job postings -- Customer wins and losses, especially your wins/losses -- Analyst and review coverage -- Partnership announcements - -## Feature Comparison Matrices - -### Building a Feature Comparison - -1. Define capability areas: Group features into functional categories that matter to buyers, not your internal architecture. Use the categories buyers use when evaluating. -2. List specific capabilities: Under each area, list the specific features or capabilities to compare. -3. Rate each competitor: Use a consistent rating scale. - -### Rating Scale Options - -Simple, recommended for most cases: -- Strong: Market-leading capability. Deep functionality, well-executed. -- Adequate: Functional capability. Gets the job done but is not differentiated. -- Weak: Exists but limited. Significant gaps or poor execution. -- Absent: Does not have this capability. - -Detailed, for deep-dive comparisons: -- 5: Best in class. Defines the standard others aspire to. -- 4: Strong. Fully featured and well-executed. -- 3: Adequate. Meets basic needs without differentiation. -- 2: Limited. Exists but with significant gaps. -- 1: Minimal. Barely functional or in early beta. -- 0: Absent. Not available. - -### Comparison Matrix Template - -```text -| Capability Area | Our Product | Competitor A | Competitor B | -|----------------|-------------|-------------|-------------| -| [Area 1] | | | | -| [Feature 1] | Strong | Adequate | Absent | -| [Feature 2] | Adequate | Strong | Weak | -| [Area 2] | | | | -| [Feature 3] | Strong | Strong | Adequate | -``` - -### Tips for Feature Comparison - -- Rate based on real product experience, customer feedback, and reviews, not just marketing claims. -- Features exist on a spectrum. "Has feature X" is less useful than "How well does it do X?" -- Weight the comparison by what matters to target customers, not by total feature count. -- Update regularly because feature comparisons get stale fast. -- Be honest about where competitors are ahead. A comparison that always shows us winning is not credible. -- Include why each capability area matters. Not all features matter equally to buyers. - -## Positioning Analysis Frameworks - -### Positioning Statement Analysis - -For each competitor, extract their positioning: - -Template: For [target customer] who [need/problem], [Product] is a [category] that [key benefit]. Unlike [competitor/alternative], [Product] [key differentiator]. - -Sources for positioning: -- Homepage headline and subheadline -- Product description on app stores or review sites -- Sales pitch decks if available from prospects or public materials -- Analyst briefing materials -- Earnings call language for public companies - -### Message Architecture Analysis - -How does each competitor communicate value? - -- **Level 1 - Category**: What category do they claim? CRM, project management, collaboration platform, etc. -- **Level 2 - Differentiator**: What makes them different within that category? AI-powered, all-in-one, developer-first, etc. -- **Level 3 - Value Proposition**: What outcome do they promise? Close deals faster, ship products faster, never miss a deadline, etc. -- **Level 4 - Proof Points**: What evidence do they provide? Customer logos, metrics, awards, case studies. - -### Positioning Gaps and Opportunities - -Look for: -- **Unclaimed positions**: Value propositions no competitor owns that matter to buyers. -- **Crowded positions**: Claims every competitor makes that have lost meaning. -- **Emerging positions**: New value propositions driven by market changes such as AI, remote work, or compliance. -- **Vulnerable positions**: Claims competitors make that they cannot fully deliver on. - -## Win/Loss Analysis Methodology - -### Conducting Win/Loss Analysis - -Win/loss analysis reveals why you actually win and lose deals. It is the most actionable competitive intelligence. - -Data sources: -- CRM notes from sales team: available immediately, but biased -- Customer interviews shortly after decision: most valuable, least biased -- Churned customer surveys or exit interviews -- Prospect surveys for lost deals - -### Win/Loss Interview Questions - -For wins: -- What problem were you trying to solve? -- What alternatives did you evaluate? -- Why did you choose us over alternatives? -- What almost made you choose someone else? -- What would we need to lose for you to reconsider? - -For losses: -- What problem were you trying to solve? -- What did you end up choosing? Why? -- Where did our product fall short? -- What could we have done differently? -- Would you reconsider us in the future? Under what conditions? - -### Analyzing Win/Loss Data - -- Track win/loss reasons over time. Are patterns changing? -- Segment by deal type: enterprise versus SMB, new versus expansion, industry vertical. -- Identify the top 3-5 reasons for wins and losses. -- Distinguish product reasons such as features and quality from non-product reasons such as pricing, brand, relationship, and timing. -- Calculate competitive win rates by competitor: what percentage of deals involving each competitor do you win? - -### Common Win/Loss Patterns - -- **Feature gap**: Competitor has a specific capability you lack that is a dealbreaker. -- **Integration advantage**: Competitor integrates with tools the buyer already uses. -- **Pricing structure**: Not always cheaper; sometimes a different pricing model such as per-seat versus usage-based fits better. -- **Incumbent advantage**: Buyer sticks with what they have because switching cost is too high. -- **Sales execution**: Better demo, faster response, more relevant case studies. -- **Brand/trust**: Buyer chooses the safer or more well-known option. - -## Market Trend Identification - -### Sources for Trend Identification - -- Industry analyst reports: Gartner, Forrester, IDC for market sizing and trends. -- Venture capital: What are VCs funding? Investment themes signal where smart money sees opportunity. -- Conference themes: What are industry events focusing on? What topics draw the biggest audiences? -- Technology shifts: New platforms, APIs, or capabilities that enable new product categories. -- Regulatory changes: New regulations that create requirements or opportunities. -- Customer behavior changes: How are user expectations evolving? -- Talent movement: Where are top people going? What skills are in demand? - -### Trend Analysis Framework - -For each trend identified: - -1. **What is changing?** Describe the trend clearly and specifically. -2. **Why now?** What is driving this change: technology, regulation, behavior, economics? -3. **Who is affected?** Which customer segments or market categories? -4. **What is the timeline?** Is this happening now, in 1-2 years, or 3-5 years? -5. **What is the implication for us?** How should this influence product strategy? -6. **What are competitors doing?** How are competitors responding to this trend? - -### Separating Signal From Noise - -- **Signals**: Trends backed by behavioral data, growing investment, regulatory action, or customer demand. -- **Noise**: Trends backed only by media hype, conference buzz, or competitor announcements without customer traction. -- Test trends against your own customer data: are your customers asking for this or experiencing this change? -- Be wary of trend-of-the-year hype cycles. Many trends that dominate industry conversation do not materially affect customers for years. - -### Strategic Response Options - -For each significant trend: -- **Lead**: Invest early and try to define the category or approach. High risk, high reward. -- **Fast follow**: Wait for early signals of customer demand, then move quickly. Lower risk but harder to differentiate. -- **Monitor**: Track the trend but do not invest yet. Set triggers for when to act. -- **Ignore**: Explicitly decide this trend is not relevant to your strategy. Document why. - -The right response depends on competitive position, customer base, resources, and trend speed. - -## Output Format - -Use clear headers and tables for feature comparisons. Keep strategic implications concise and actionable. - -Return this structure: - -```text -# Competitive Brief: [Competitor(s) or Feature Area] - -## Scope -- Competitor(s) or feature area: -- Focus: -- Decision context: -- Sources used: -- Date: - -## Executive Summary -- Bottom line: -- Biggest competitive strength: -- Biggest competitive weakness: -- Highest-priority strategic implication: - -## Competitive Landscape -[Direct, indirect, adjacent, and substitute competitors.] - -## Competitor Overview -[Overview per competitor.] - -## Feature Comparison -[Capability matrix plus notes on evidence and caveats.] - -## Positioning Analysis -[Positioning statement, message architecture, gaps, and opportunities.] - -## Strengths and Weaknesses -[Evidence-based strengths and weaknesses per competitor.] - -## Opportunities -[Strategic opportunities and customer gaps.] - -## Threats -[Competitive threats and nightmare scenarios.] - -## Win/Loss Signals -[Available win/loss patterns, questions to investigate, and deal implications.] - -## Market Trends -[Relevant trends, signal/noise assessment, and strategic response.] - -## Strategic Implications -[Build, accelerate, deprioritize, differentiate, parity, positioning, and monitoring recommendations.] - -## Follow-Ups -[Recommended deeper dives, executive summary, battle card, how-to-win guide, or monitoring plan.] -``` - -## Tips - -- Be honest about competitor strengths. Dismissing competitors makes the analysis useless. -- Focus on what matters to customers, not what matters to product teams. -- Pricing is hard to compare fairly. Note caveats such as different packaging, usage-based versus seat-based pricing, and enterprise custom pricing. -- Job postings are underrated competitive intelligence. A competitor hiring ML engineers signals a strategic direction. -- Customer reviews are valuable because they reveal what real users love and hate, less filtered by marketing. -- The most valuable part of competitive analysis is the "so what": strategic implications. Do not skip it. -- Competitive analysis has a shelf life. Note the date and flag areas that change quickly. diff --git a/.claude/skills/competitive-brief/references/pm-skills-main-merge.md b/.claude/skills/competitive-brief/references/pm-skills-main-merge.md deleted file mode 100644 index 39261a4b..00000000 --- a/.claude/skills/competitive-brief/references/pm-skills-main-merge.md +++ /dev/null @@ -1,191 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM sources when the competitive artifact must become sales-ready battlecard material, not only product strategy research. - -## Routing Signals - -- competitive battlecard -- sales battlecard -- objection handling -- win loss - -## pm-go-to-market/skills/competitive-battlecard/SKILL.md - -## Competitive Battlecard - -Create a concise, sales-ready battlecard for use against a specific competitor. - -### Context - -You are creating a competitive battlecard for **$ARGUMENTS**. - -Use web search to research the competitor's current product, pricing, positioning, and recent changes. If the user provides files (feature lists, win/loss data, sales call notes), read them first. - -### Instructions - -1. **Research the competitor** (use web search): - - Current product offerings and features - - Pricing tiers and model - - Target market and positioning - - Recent product launches or changes - - Known strengths and weaknesses - - Customer reviews and sentiment (G2, Capterra, Reddit) - -2. **Create the battlecard** with these sections: - - ### Company Overview - - Founded, HQ, funding/revenue (if public) - - Target market and ICP - - Positioning in one sentence - - ### Quick Comparison - - | Capability | Us | Them | Winner | - |---|---|---|---| - | [Feature area 1] | [Our approach] | [Their approach] | [Us/Them/Tie] | - | [Feature area 2] | ... | ... | ... | - | Pricing | ... | ... | ... | - | Support | ... | ... | ... | - - ### Where We Win - - [Advantage 1]: [Proof point or customer quote] - - [Advantage 2]: [Specific capability they lack] - - [Advantage 3]: [Better approach with reasoning] - - ### Where They Win - - [Their strength 1]: [Our counter-positioning] - - [Their strength 2]: [How we mitigate this gap] - - ### Common Objections & Responses - - | Prospect Says | Respond With | - |---|---| - | "Competitor X has [feature]" | "[Our alternative approach and why it's better for them]" | - | "They're cheaper" | "[Value framing: total cost of ownership, ROI, hidden costs]" | - | "They're more established" | "[Our advantages: speed, innovation, focus, support]" | - - ### Landmines to Plant - Questions to ask the prospect that highlight competitor weaknesses: - - "How important is [area where we excel] to your team?" - - "Have you evaluated [specific capability they lack]?" - - ### Win/Loss Patterns - - We tend to win when: [pattern] - - We tend to lose when: [pattern] - - Key differentiator in competitive deals: [what tips the scale] - -3. **Keep it scannable**: Sales reps need to reference this during calls. Use tables, bold text, and short bullets. - -Save as markdown. Format for easy printing or sharing in Notion/Confluence. - ---- - -### Further Reading - -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## pm-market-research/skills/competitor-analysis/SKILL.md - -## Purpose -Conduct a comprehensive competitive analysis to understand the landscape, identify 5 direct competitors, and uncover differentiation opportunities. This skill maps competitive positioning, synthesizes competitor strengths and weaknesses, and highlights opportunities for strategic differentiation. - -## Instructions - -You are a strategic product analyst and competitive intelligence expert specializing in competitive positioning and market landscape mapping. - -### Input -Your task is to analyze the competitive landscape for **$ARGUMENTS** in the **[market/industry segment]** (if specified). - -Conduct web research to identify direct competitors. If the user provides market research, competitor data, pricing sheets, feature comparisons, or customer feedback about competitors, read and analyze them directly. Synthesize data into a comprehensive competitive view. - -### Analysis Steps (Think Step by Step) - -1. **Market Scoping**: Define the market, industry, and addressable customer base for $ARGUMENTS -2. **Competitor Identification**: Use web search to identify 5 primary direct competitors -3. **Competitive Intelligence**: Research each competitor's positioning, features, pricing, go-to-market strategy -4. **Strengths & Weaknesses**: Assess competitor capabilities, limitations, and market positioning -5. **Differentiation Mapping**: Identify gaps, overlaps, and opportunities for $ARGUMENTS to differentiate -6. **Strategic Synthesis**: Develop insights about competitive dynamics and future threats - -### Output Structure - -**Market Overview & Definition** -- Market size and growth trends -- Primary customer segments and use cases -- Key success factors in this market -- Market dynamics and competitive intensity - -**Competitive Set Summary** -- 5 primary direct competitors identified -- Market positions: leaders, challengers, niche players -- Estimated market share or positioning -- Notable adjacent or indirect competitors - -For each of the 5 competitors: - -**Competitor Profile** -- Company name, founding date, funding/status -- Primary market focus and customer segments served -- Estimated market share or customer base size -- Market positioning and go-to-market strategy - -**Core Product Strengths** -- Key features and capabilities -- Unique competitive advantages -- Customer value proposition -- Technology differentiation or moats -- Customer satisfaction and retention signals - -**Product Weaknesses & Gaps** -- Missing features or use cases -- Known limitations or pain points for customers -- Technical or operational weaknesses -- Market positioning gaps -- Customer dissatisfaction areas - -**Business Model & Pricing** -- Pricing structure (per-seat, per-usage, flat-fee, freemium, etc.) -- Price point(s) in market -- Go-to-market channels and sales motion -- Revenue model and growth stage - -**Competitive Threats & Advantages** -- How this competitor threatens $ARGUMENTS -- Existing customer base and switching costs -- Strategic partnerships or ecosystems -- Recent product updates or strategic moves - -**Differentiation Opportunities for $ARGUMENTS** - -- Unmet customer needs across competitive set -- Feature/pricing/UX opportunities to stand out -- Target segments underserved by competitors -- Jobs-to-be-done not effectively solved by competitors -- Channel or go-to-market approaches not yet deployed -- Potential partnerships or integrations competitors lack - -**Competitive Positioning Recommendation** -- Recommended competitive positioning for $ARGUMENTS -- Key differentiators to emphasize -- Segments or use cases to target or avoid -- Competitive threats to monitor -- 12-18 month competitive risks and opportunities - -## Best Practices - -- Research current competitor websites, pricing pages, and customer reviews -- Use web search to identify product launches, funding, executive moves -- Distinguish between direct competitors and adjacent alternatives -- Validate competitive insights across multiple sources -- Identify both obvious and subtle differentiation opportunities -- Consider customer pain points not yet addressed in market -- Look for emerging competitors or new market entrants -- Flag competitors gaining traction or gaining market share -- Consider long-term competitive dynamics and market shifts - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) diff --git a/.claude/skills/competitive-parity-and-strategic-differentiation/SKILL.md b/.claude/skills/competitive-parity-and-strategic-differentiation/SKILL.md deleted file mode 100644 index 2f3963d1..00000000 --- a/.claude/skills/competitive-parity-and-strategic-differentiation/SKILL.md +++ /dev/null @@ -1,286 +0,0 @@ ---- -name: competitive-parity-and-strategic-differentiation -description: >- - Competitive parity and strategic differentiation. Use when the user needs a product workflow - for product strategy related to competitive parity and strategic differentiation. Trigger - terms: competitive-analysis, differentiation, product-strategy, decision-making. ---- - - - -# Competitive parity and strategic differentiation - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `competitive-parity-and-strategic-differentiation` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Competitive parity and strategic differentiation strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Competitive parity and strategic differentiation**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPETITIVE_FEATURE}} -- {{COMPETITOR_CONTEXT}} -- {{OUR_PRODUCT_STRATEGY}} - - -GOAL -Produce a high-quality deliverable for: "Competitive parity and strategic differentiation". -Success metric: -- Produces a clear parity-vs-differentiation decision grounded in competitive context and product strategy. -- Distinguishes table-stakes matching from strategic differentiation, leapfrogging, or deliberate skipping. -- Provides actionable implementation guidance and monitoring signals tied to the recommendation. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPETITIVE_FEATURE}}`, `{{COMPETITOR_CONTEXT}}`, and `{{OUR_PRODUCT_STRATEGY}}`; if information is missing, state assumptions explicitly. -- Analyze competitor capability, UX, target users/use cases, and positioning before recommending action. -- Classify strategic importance as one of: Table Stakes, Valuable Differentiator, Non-Essential, Strategic Distraction. -- Evaluate four paths: do better, do differently, leapfrog, skip. -- Frame decisions as strategy-led (serving our users and positioning), not reactive feature copying. -- Include user/market implications, recommendation rationale, implementation guidance, and ongoing monitoring metrics/signals. -- Keep claims specific and evidence-oriented; avoid generic statements. - -FORMAT -Return exactly this structure: - - - -**What Competitor Built:** -[Describe capabilities and UX approach] - -**Why They Built It:** -[Infer strategic intent: what user need, what market position, what business goal] - -**Who It Serves:** -[Target users and use cases] - -**How They Positioned It:** -[Marketing/messaging angle] - -**Market Reception:** -[If known: user feedback, adoption, impact] - - - -**Classification:** -[Select one: Table Stakes / Valuable Differentiator / Non-Essential / Strategic Distraction] - -**Rationale:** -[Explain the classification] - -**Evidence:** -- User feedback: [What users say about this] -- Market trends: [Industry direction] -- Win/loss data: [If relevant to deals] -- Strategic alignment: [How it fits our positioning] - -**Risk of Not Having:** -- Deal losses: [High/Medium/Low] -- User churn: [High/Medium/Low] -- Perception damage: [High/Medium/Low] - -**Opportunity Cost:** -[What else could we build with the same investment] - - - - -**Do It Better:** -[How we could execute this more effectively than competitor] - -**Our Advantages:** -[What unique capabilities or context we have] - -**User Value:** -[How users benefit from our better approach] - -**Effort:** -[High/Medium/Low to achieve superior execution] - - - -**Do It Differently:** -[Alternative approach that serves our users better] - -**Why This Works for Us:** -[How it aligns with our strategy and user base] - -**User Value:** -[Why users would prefer this approach] - -**Risks:** -[What could go wrong with being different] - - - -**Leapfrog:** -[More advanced approach that makes competitor's solution look dated] - -**Innovation:** -[What's novel about this approach] - -**User Value:** -[Why this is significantly better] - -**Feasibility:** -[Can we actually pull this off? What's required?] - -**Risk:** -[Execution risk and market risk] - - - -**Skip Entirely:** -[Case for not building this at all] - -**Alternative:** -[What we do instead that serves users differently] - -**Rationale:** -[Why skipping aligns with our strategy] - -**Communication:** -[How to position our absence of this feature] - - - - -**User Expectations:** -[What users now expect based on competitor precedent] - -**Expectation Flexibility:** -[Where users are open to alternatives vs. locked into patterns] - -**Innovation Readiness:** -[Would users welcome innovation here or is familiarity valued?] - -**Education Required:** -[If we differentiate, what teaching is needed?] - -**Competitive Messaging:** -[How to position our approach vs. competitor] - - - -**Recommendation:** [Match / Differentiate / Leapfrog / Skip] - -**Specific Approach:** -[Detailed description of what to build and how] - -**Rationale:** -[Why this approach is strategically right] - -**Success Criteria:** -[How we'll know this was the right decision] - -**Timeline:** -[When to execute] - -**Resources Required:** -[Team, time, budget] - - - -**If Match:** -- Core capabilities to replicate: [List] -- Where we can simplify: [Opportunities] -- Where we must differentiate UX: [To fit our product] - -**If Differentiate:** -- Key differences: [What's different] -- User communication: [How to explain our approach] -- Risk mitigation: [How to validate innovation] - -**If Leapfrog:** -- Technical requirements: [What's needed] -- User research: [Validation needed] -- Phasing: [How to de-risk] - -**If Skip:** -- Alternative solution: [What we do instead] -- Communication strategy: [How to position absence] -- Monitoring: [What signals would change this decision] - - - -[What to track to validate the decision: -- Competitive intelligence: [Watch for X] -- User feedback: [Listen for Y] -- Market trends: [Monitor Z] -- Performance metrics: [Track A, B, C]] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or materially incomplete. -- `Classification` is missing or not one of the allowed categories. -- Recommendation is missing or not aligned with prior analysis/evidence. -- User and market implications are omitted or disconnected from the recommended strategy. -- Implementation guidance does not map to the selected recommendation path. -- Monitoring signals/metrics are missing or non-actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/complex-problem-structuring-into-actionable-recommendations/SKILL.md b/.claude/skills/complex-problem-structuring-into-actionable-recommendations/SKILL.md deleted file mode 100644 index 1e72c223..00000000 --- a/.claude/skills/complex-problem-structuring-into-actionable-recommendations/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: complex-problem-structuring-into-actionable-recommendations -description: >- - Complex problem structuring into actionable recommendations. Use when the user needs a - product workflow for decision making related to complex problem structuring into actionable - recommendations. Trigger terms: decision-making, problem-structuring, analysis, consulting. ---- - - - -# Complex problem structuring into actionable recommendations - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `complex-problem-structuring-into-actionable-recommendations` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: Complex problem structuring into actionable recommendations product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Complex problem structuring into actionable recommendations**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Structure a complex problem into a clear analysis and actionable recommendation. -Success metric: -- Produces a concise problem simplification with key issues/stakeholders. -- Includes both deductive and inductive analysis streams. -- Synthesizes insights into a concrete recommendation with rationale. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required steps: - 1. Simplify the problem into core components and stakeholders. - 2. Perform deductive analysis (top-down logic and option tree). - 3. Perform inductive analysis (specific evidence/patterns/examples). - 4. Synthesize both analyses (alignment/conflicts and key insight). - 5. Recommend an actionable course of action. -- Keep reasoning objective, explicit, and grounded in `PROBLEM_STATEMENT`. -- Clearly label assumptions if evidence is incomplete. - -FORMAT -Return exactly this structure: - - - -[Provide a concise summary of the simplified problem] - - - -[Present your logical tree of options and ideas, including key considerations and potential outcomes] - - - -[Discuss specific examples, data points, or patterns you've identified and their implications] - - - -[Explain how your deductive and inductive analyses complement or contrast with each other, and what overall insights they provide] - - - -[Clearly state your recommended course of action, explaining why it's the best approach based on your analysis] - - - -FAILURE -- Required schema is missing or malformed. -- Any required analysis section is missing or materially incomplete. -- Deductive and inductive analyses are not clearly distinguished. -- Recommendation is generic or not supported by prior analysis. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/comprehensive-use-cases-from-user-input-for-product-strategy/SKILL.md b/.claude/skills/comprehensive-use-cases-from-user-input-for-product-strategy/SKILL.md deleted file mode 100644 index 97100b50..00000000 --- a/.claude/skills/comprehensive-use-cases-from-user-input-for-product-strategy/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: comprehensive-use-cases-from-user-input-for-product-strategy -description: >- - Comprehensive use cases from user input for product strategy. Use when the user needs a - product workflow for user research related to comprehensive use cases from user input for - product strategy. Trigger terms: user-research, use-cases, product-strategy. ---- - - - -# Comprehensive use cases from user input for product strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `comprehensive-use-cases-from-user-input-for-product-strategy` -- **Lifecycle**: Strategize -- **Category**: Discovery -- **Primary artifact**: Comprehensive use cases from user input for product strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Comprehensive use cases from user input for product strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Comprehensive use cases from user input for product strategy. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{USER_INPUT}}` and generate one or more distinct product strategy use cases. -- For each use case, include: -- `Problem` (in user language). -- `Persona` (specific segment and context). -- `Alternatives` (direct and indirect). -- `Frequency` (time-based occurrence). -- `Why` (core motivation/value driver). -- `Consideration Time` (decision horizon). -- Keep output human-readable and structured with clear headings and list formatting. -- Ensure each use case is materially different and strategically useful. - -FORMAT -Return exactly this structure: - -Use Case 1: [Brief Title] -Problem: [Problem description] -Persona: [Persona description] -Alternatives: -- [Alternative 1] -- [Alternative 2] -Frequency: [Frequency description] -Why: [Core motivation] -Consideration Time: [Estimated time] - -[Repeat "Use Case N" blocks as needed] - -FAILURE -- Output is not human-readable structured use-case blocks. -- Any use case is missing one or more required components. -- Use cases are repetitive, generic, or not grounded in `{{USER_INPUT}}`. -- Alternatives/frequency/consideration-time fields are vague or non-actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/conflicting-stakeholder-requirements-to-balanced-design/SKILL.md b/.claude/skills/conflicting-stakeholder-requirements-to-balanced-design/SKILL.md deleted file mode 100644 index 0eb50a8c..00000000 --- a/.claude/skills/conflicting-stakeholder-requirements-to-balanced-design/SKILL.md +++ /dev/null @@ -1,316 +0,0 @@ ---- -name: conflicting-stakeholder-requirements-to-balanced-design -description: >- - Conflicting stakeholder requirements to balanced design approach. Use when the user needs a - product workflow for stakeholder management related to conflicting stakeholder requirements - to balanced design approach. Trigger terms: stakeholder-management, design-strategy, - conflict-resolution. ---- - - - -# Conflicting stakeholder requirements to balanced design approach - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `conflicting-stakeholder-requirements-to-balanced-design` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Conflicting stakeholder requirements to balanced design approach UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Conflicting stakeholder requirements to balanced design approach**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONFLICTING_REQUIREMENTS}} -- {{STAKEHOLDER_PRIORITIES}} -- {{PROJECT_CONTEXT}} -- {{USER_RESEARCH_INSIGHTS}} -- {{TECHNICAL_CONSTRAINTS}} - - -GOAL -Produce a high-quality deliverable for: Conflicting stakeholder requirements to balanced design approach. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reconcile `{{CONFLICTING_REQUIREMENTS}}` using `{{STAKEHOLDER_PRIORITIES}}`, `{{PROJECT_CONTEXT}}`, `{{USER_RESEARCH_INSIGHTS}}`, and `{{TECHNICAL_CONSTRAINTS}}`. -- Map conflict types, stakeholder positions, severity, and dependencies. -- Identify root causes, then propose win-win solutions and explicit tradeoffs. -- Provide a recommendation with rationale, decision framework, communication plan, and validation plan. - -FORMAT -Return exactly this structure: - - - -**Project:** [Project name] -**Conflicting Requirements Count:** [Number of major conflicts identified] -**Stakeholders Involved:** [List key stakeholders and their roles] -**Conflict Severity:** [Low/Medium/High - overall assessment] -**Resolution Approach:** [Win-win solutions possible / Tradeoffs required / Phased approach needed] -**Decision Timeline:** [When final decision needed] -**Recommendation:** [One-sentence summary of proposed path forward] - - - -Map each significant conflict clearly with all relevant details, stakeholder positions, user research insights, and dependencies. - -## Conflict #1: [Name] - -**Requirement A:** [Full description] -**Stakeholder:** [Name, role, underlying goal, success metric] - -**Requirement B:** [Full description] -**Stakeholder:** [Name, role, underlying goal, success metric] - -**Conflict Type:** [Classification] -**Severity:** [Level and why] -**Impact:** [What's affected] -**User Research:** [What data says] -**Alignment:** [Who supports each side] -**Dependencies:** [Related conflicts] - -[Repeat for each major conflict] - - - -Identify fundamental causes driving conflicts: - -**[Root Cause Category]:** -[Detailed explanation of this underlying issue] -**Examples:** [Specific manifestations] -**โ†’ Root cause:** [One-line summary] - -[Continue for all root cause categories identified] - -**Key Insights:** -[Major patterns and observations] - - - -## Solution for Conflict #[X]: [Name] - -**Approach: [Solution Name]** - -**How It Works:** -[Detailed 3-5 bullet explanation of the creative solution] - -**Why It's Win-Win:** -- โœ… [Stakeholder A benefit] -- โœ… [Stakeholder B benefit] -- โœ… [User benefit] -- โœ… [Business benefit] - -**Implementation:** -- Phase 1: [Details, timeline] -- Phase 2: [Details, timeline] -- Phase 3: [Details, timeline] - -**Validation:** -[How to test this works] - -**Potential Risks:** -[What could go wrong and mitigations] - -[Repeat for each win-win solution] - - - -## For Conflict #[X]: [Name] (Requires Tradeoff) - -### Option A: [Name] (Favors [Stakeholder]) - -**Approach:** [What we'd do] -**Gains:** [What winning party gets] -**Losses:** [What losing party sacrifices] -**User Impact:** [Effects on users] -**Business Impact:** -- Short-term: [Impact] -- Long-term: [Impact] -**Complexity:** [Level] -**Timeline:** [Duration] -**Risk:** [Assessment] -**Reversibility:** [How hard to change] - -### Option B: [Name] (Favors [Other Stakeholder]) - -[Same structure] - -### Option C: [Balanced Approach] (Recommended) - -**Approach:** [Compromise solution] -**Everyone Gains Partially:** [How it balances] -**Implementation:** [Detailed plan] -**Quality Gates:** [Must-meet criteria] -**Why Recommended:** [Justification] -**Tradeoffs Accepted:** [Explicit acknowledgment] -**Success Metrics:** [How to measure] - -[Repeat for conflicts needing tradeoff decisions] - - - -## For Unresolved Conflicts - -**Decision Criteria:** -1. [Criterion]: [Description, weight, how to evaluate] -2. [Criterion]: [Description, weight, evaluation method] -[Continue for all criteria] - -**Decision Authority Matrix:** -[Table showing who decides what] - -**When Stakeholders Disagree:** -1. Try data-driven resolution -2. Structured discussion -3. Escalation if needed -4. Document and commit - -**Information Needed:** [Data gaps to fill] -**Timeline:** [When decisions must be made] -**Validation:** [How to verify decisions work] -**Adjustment Triggers:** [Signals to reconsider] -**Rollback Plan:** [How to reverse if wrong] - - - -## Stakeholder Alignment Strategy - -**Pre-Meeting 1:1s:** -[Process for individual conversations] - -**Facilitated Group Session:** -**Agenda:** -1. Present conflicts (15 min) -2. Root causes (10 min) -3. Win-win solutions (20 min) -4. Tradeoff discussion (30 min) -5. Make decisions (15 min) -6. Document (10 min) - -**Ground Rules:** [Discussion norms] -**Materials:** [What's needed] - -**Documentation:** -[Decision record template with rationale, commitments, metrics, review dates] - -**Ongoing Communication:** -- Weekly syncs -- Monthly metrics reviews -- Quarterly retrospectives - - - -## Testing Assumptions - -### Decision: [Name] - -**Assumptions:** -1. [Assumption to test] -2. [Assumption to test] - -**Validation Approach:** -- Phase 1: [Method, timeline, criteria] -- Phase 2: [Method, timeline, criteria] -- Phase 3: [Method, timeline, criteria] - -**Instrumentation:** [What data to collect] -**User Research:** [Qualitative validation] -**Success Criteria:** [Specific thresholds] - -**Adjustment Plan:** -If [assumption] proves wrong: [What we'll do] - -**Learning Documentation:** [How to capture insights] - -[Repeat for each major decision] - - - -## Preventing Future Conflicts - -**1. [Improvement]** -- Problem Solved: [Pattern prevented] -- Implementation: [How to do it] -- Owner: [Who's responsible] -- Timeline: [When] - -[Continue for all process improvements identified] - - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Conflict mapping or root cause analysis is shallow or not grounded in inputs. -- Tradeoff analysis or recommendation lacks explicit rationale. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/conversation-summaries-from-meeting-transcripts/SKILL.md b/.claude/skills/conversation-summaries-from-meeting-transcripts/SKILL.md deleted file mode 100644 index 1f427915..00000000 --- a/.claude/skills/conversation-summaries-from-meeting-transcripts/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: conversation-summaries-from-meeting-transcripts -description: >- - Conversation summaries from meeting transcripts. Use when the user needs a product workflow - for project management related to conversation summaries from meeting transcripts. Trigger - terms: meetings, summarization, note-taking, communication. ---- - - - -# Conversation summaries from meeting transcripts - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `conversation-summaries-from-meeting-transcripts` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Conversation summaries from meeting transcripts stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Conversation summaries from meeting transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONVERSATION}} - - -GOAL -Produce a high-quality deliverable for: Conversation summaries from meeting transcripts. -Success metric: -- Produces a structured summary of major topics with correct hierarchy. -- Extracts explicit actions with owners and ADHD-friendly step breakdowns. -- Keeps summary faithful to the transcript without fabrication. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CONVERSATION}}`; if information is missing, state assumptions explicitly. -- Summarize with nested bullets reflecting topic hierarchy and relationships. -- Identify explicit actions with: - - `**Action:**` statement, - - `**Who:**` owner, - - concise numbered ADHD-friendly steps. -- Keep language clear and concise; avoid invented facts or inferred decisions not in transcript. -- Output must be inside `` tags only. - -FORMAT -Return exactly this structure: - - -โ€ข Main topic 1 - โ—ฆ Subtopic 1.1 - โ–ช Detail 1.1.1 - โ–ช Detail 1.1.2 - โ—ฆ Subtopic 1.2 - โ–ช Detail 1.2.1 - - Sub-detail 1.2.1.1 - -โ€ข Main topic 2 - โ—ฆ Subtopic 2.1 - โ–ช **Action: [Description of the action]** - โ–ช **Who: [Person responsible]** - โ–ช Steps for ADHD individuals: - 1. First step - 2. Second step - 3. Third step - - โ—ฆ Subtopic 2.2 - โ–ช Detail 2.2.1 - - -FAILURE -- `` wrapper is missing, malformed, or incomplete. -- Nested structure does not reflect major topics and supporting details. -- Actions are missing `**Action:**`, `**Who:**`, or ADHD step breakdown. -- Content includes fabricated points not present in transcript. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/create-viz/SKILL.md b/.claude/skills/create-viz/SKILL.md deleted file mode 100644 index 3a0138c0..00000000 --- a/.claude/skills/create-viz/SKILL.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: create-viz -description: >- - Create publication-quality visualizations with Python. Use when turning query results or a - DataFrame into a chart, selecting the right chart type for a trend or comparison, generating - a plot for a report or presentation, or creating an interactive chart with hover and zoom. ---- - - - -# Create Viz - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `create-viz` -- **Lifecycle**: Design -- **Category**: Analytics -- **Primary artifact**: Create Viz UX/design review with findings, constraints, fixes, and acceptance checks - -Create publication-quality data visualizations using Python. - -## Argument Hint - -` [chart type]` - -## Usage - -```text -/create-viz [chart type] [additional instructions] -``` - -## Workflow - -### 1. Understand Request - -Determine: -- Data source: query results, pasted data, CSV/XLSX, existing DataFrame, or data to query. -- Chart type: explicit or to be recommended. -- Purpose: exploration, presentation, report, dashboard component. -- Audience: technical, executive, external, or internal. - -### 2. Get Data - -If data tools are connected, query and load results into pandas. - -If data is pasted or uploaded, parse and clean it. Convert dates, numeric columns, categories, and nulls deliberately. - -### 3. Select Chart Type - -If chart type is not specified, choose based on relationship: -- Trend over time: line chart. -- Category comparison or ranking: bar chart, horizontal for many categories. -- Part-to-whole: stacked bar or area. Avoid pie charts unless fewer than six categories and rough proportions are enough. -- Distribution: histogram, box plot, or violin plot. -- Correlation: scatter plot. -- Matrix: heatmap. -- Flow: Sankey. -- Geographic: map if location data exists. - -Briefly explain the recommendation. - -### 4. Generate Visualization - -Use: -- matplotlib + seaborn for static publication-quality charts. -- plotly for interactive charts with hover, zoom, or HTML export. - -Always include: -- Clear title that states the insight. -- Axis labels and units. -- Appropriate number formatting. -- Colorblind-friendly palette. -- Removed chart junk. -- Saved output file. - -### 5. Quality Checks - -- Bar charts start at zero. -- Labels and legends are readable. -- Categories are sorted meaningfully. -- Precision is appropriate. -- Color is meaningful, not decorative. -- Chart works in grayscale or has labels/line styles. -- Include data source and date range when known. - -### 6. Save and Present - -Save as PNG for static charts or HTML for interactive charts. Display or reference the file, include the code used, and suggest useful variants. - -## Python Defaults - -Use pandas, matplotlib, seaborn, and plotly where available. Prefer explicit imports, stable filenames, and reproducible code. For reports and presentations, use larger fonts and higher contrast. diff --git a/.claude/skills/creative-solution-generation-from-de-bono-s-lateral-thinking/SKILL.md b/.claude/skills/creative-solution-generation-from-de-bono-s-lateral-thinking/SKILL.md deleted file mode 100644 index 4ae9a65f..00000000 --- a/.claude/skills/creative-solution-generation-from-de-bono-s-lateral-thinking/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: creative-solution-generation-from-de-bono-s-lateral-thinking -description: >- - Creative solution generation from De Bono's lateral thinking methods. Use when the user - needs a product workflow for ideation & creativity related to creative solution generation - from de bono's lateral thinking methods. Trigger terms: ideation, creativity, - lateral-thinking, de-bono, problem-solving, product-management. ---- - - - -# Creative solution generation from De Bono's lateral thinking methods - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `creative-solution-generation-from-de-bono-s-lateral-thinking` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Creative solution generation from De Bono's lateral thinking methods product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Creative solution generation from De Bono's lateral thinking methods**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM}} - - -GOAL -Produce a high-quality deliverable for: "Creative solution generation from De Bono's lateral thinking methods". -Success metric: -- Produces exactly 20 lateral provocations (`PO`) tied to the problem statement. -- Each provocation is converted into at least one plausible new option through a named De Bono movement approach. -- Provocations and options show clear variety (reversal, exaggeration, distortion, random connection). -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM}}`; if context is incomplete, state assumptions explicitly. -- Generate exactly 20 provocations; each must begin with `PO:`. -- Ensure coverage across provocation types: - - reversal, - - exaggeration, - - distortion, - - random connection. -- For each provocation, apply at least one movement approach: - - Abandon, Ideal case, Reversal, Exaggeration, Fortuity, or Falsification. -- For each provocation + approach, produce at least one concrete new option tied back to the original problem. -- Keep options specific enough to be testable/explorable (not generic slogans). - -FORMAT -Return exactly this structure: - - - -PO: [Your provocation statement] -Approach: [Approach used] -New option: [Resulting idea or solution] - - - -PO: [Your provocation statement] -Approach: [Approach used] -New option: [Resulting idea or solution] - - -[Continue for all 20 provocations] - - -FAILURE -- Root tag `` is missing, malformed, or incomplete. -- Number of provocation blocks is not exactly 20. -- One or more provocations do not start with `PO:`. -- Any provocation block is missing `Approach` or `New option`. -- Provocations lack variety across the required provocation types. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/creative-solution-generation-from-metaphorical-thinking/SKILL.md b/.claude/skills/creative-solution-generation-from-metaphorical-thinking/SKILL.md deleted file mode 100644 index 7a935ec6..00000000 --- a/.claude/skills/creative-solution-generation-from-metaphorical-thinking/SKILL.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: creative-solution-generation-from-metaphorical-thinking -description: >- - Creative solution generation from metaphorical thinking. Use when the user needs a product - workflow for ideation & creativity related to creative solution generation from metaphorical - thinking. Trigger terms: ideation, creativity, metaphor, problem-solving, - perspective-shifting. ---- - - - -# Creative solution generation from metaphorical thinking - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `creative-solution-generation-from-metaphorical-thinking` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Creative solution generation from metaphorical thinking product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Creative solution generation from metaphorical thinking**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{ISSUE}} - - -GOAL -Produce a high-quality deliverable for: "Creative solution generation from metaphorical thinking". -Success metric: -- Produces at least 3 issue metaphors with clear relevance to the issue. -- Generates 20 distinct random activities and maps each to at least one meaningful similarity. -- Selects one best metaphor from the activity list with a compelling rationale. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{ISSUE}}`; if context is incomplete, state assumptions explicitly. -- Provide at least 3 metaphors directly representing the issue. -- Generate exactly 20 random activities and avoid these examples: building a house, raising a child, cooking a meal. -- For each activity, provide at least one explicit similarity to the issue. -- Choose one best metaphor from the activity list (not from outside the list) and explain insight gained. -- Keep connections concrete enough to inspire actionable reframing (not generic one-liners). - -FORMAT -Return exactly this structure: - - - -1. [Metaphor] - [How it relates to the issue] -2. [Metaphor] - [How it relates to the issue] -3. [Metaphor] - [How it relates to the issue] -[Optional additional metaphors] - - - -1. [Activity] -2. [Activity] -... -20. [Activity] - - - -1. [Activity 1] - [Similarity to issue] -2. [Activity 2] - [Similarity to issue] -... -20. [Activity 20] - [Similarity to issue] - - - -[State the activity you chose as the best metaphor and explain why] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 issue metaphors are provided. -- Random activities count is not exactly 20. -- Any activity lacks a corresponding similarity mapping. -- Best metaphor is not selected from the listed random activities. -- Disallowed example activities are reused. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/crisis-communication-plan-from-outage-details-and-company/SKILL.md b/.claude/skills/crisis-communication-plan-from-outage-details-and-company/SKILL.md deleted file mode 100644 index b414117b..00000000 --- a/.claude/skills/crisis-communication-plan-from-outage-details-and-company/SKILL.md +++ /dev/null @@ -1,176 +0,0 @@ ---- -name: crisis-communication-plan-from-outage-details-and-company -description: >- - Crisis communication plan from outage details and company context. Use when the user needs a - product workflow for presentation & communication related to crisis communication plan from - outage details and company context. Trigger terms: incident-response, communication, - reliability, postmortem, stakeholders. ---- - - - -# Crisis communication plan from outage details and company context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `crisis-communication-plan-from-outage-details-and-company` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Crisis communication plan from outage details and company context stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Crisis communication plan from outage details and company context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{OUTAGE_DETAILS}} -- {{COMPANY_CONTEXT}} -- {{STAKEHOLDERS}} - - -GOAL -Produce a high-quality deliverable for: Crisis communication plan from outage details and company context. -Success metric: -- Produces both a stakeholder communication plan and an internal post-mortem framework. -- Communication plan is empathetic, transparent, role-specific, and time-sequenced. -- Post-mortem framework is actionable with root cause analysis, lessons, and owners/deadlines. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{OUTAGE_DETAILS}}`, `{{COMPANY_CONTEXT}}`, and `{{STAKEHOLDERS}}`; if information is missing, state assumptions explicitly. -- Analyze outage facts, company context, and stakeholder impact before drafting communications. -- Prioritize stakeholders by outage impact and urgency. -- For each stakeholder group include: - - tailored message (acknowledgment, empathy, immediate actions), - - channel(s), - - cadence/timeline, - - spokesperson and key talking points. -- Post-mortem framework must include: - - incident timeline, - - response team, - - root cause analysis, - - stakeholder/business impact, - - lessons learned, - - action items with owners and deadlines. -- Keep tone aligned with company values/style in `{{COMPANY_CONTEXT}}`. - -FORMAT -Return exactly this structure: - - - -[Stakeholder groups ranked by impact/urgency with rationale] - - - -[Shared core message acknowledging outage, empathy, and immediate actions] - - - -- Stakeholder group: [Name] - - Concerns: [Primary concerns] - - Tailored message: [Message] - - Channels: [Email/status page/social/CSM/call/etc.] - - Timeline: [Initial notice, update cadence, resolution notice] - - Spokesperson: [Role/name] - - Talking points: [Bullets] -[Repeat for each key stakeholder group] - - - - - -[Chronological sequence before/during/after outage] - - - -[People/roles involved in incident response] - - - -[Detailed root cause(s), contributing factors, and evidence] - - - -[Impact by stakeholder group and business operations] - - - -[What was learned and what should change] - - - -1. [Action] - Owner: [Role/name] - Deadline: [Date/timeframe] -2. [Action] - Owner: [Role/name] - Deadline: [Date/timeframe] -[Additional actions] - - - -FAILURE -- Either top-level required section is missing: `stakeholder_communication_plan` or `internal_postmortem_framework`. -- Any required subsection in `FORMAT` is missing, malformed, or incomplete. -- Stakeholder plans are not tailored by group or do not include channels/timeline/spokesperson. -- Post-mortem is missing root cause analysis, impact assessment, or owned action items with deadlines. -- Tone is misaligned with provided company context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/critical-flaws-in-product-requirements-tough-and-unreasonable/SKILL.md b/.claude/skills/critical-flaws-in-product-requirements-tough-and-unreasonable/SKILL.md deleted file mode 100644 index 09fcd173..00000000 --- a/.claude/skills/critical-flaws-in-product-requirements-tough-and-unreasonable/SKILL.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -name: critical-flaws-in-product-requirements-tough-and-unreasonable -description: >- - Critical flaws in product requirements (tough and unreasonable product executive). Use when - the user needs a product workflow for stakeholder management related to critical flaws in - product requirements (tough and unreasonable product executive). Trigger terms: - product-management, requirements, strategy, stakeholder-management. ---- - - - -# Critical flaws in product requirements (tough and unreasonable product executive) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `critical-flaws-in-product-requirements-tough-and-unreasonable` -- **Lifecycle**: Design -- **Category**: Delivery -- **Primary artifact**: Critical flaws in product requirements (tough and unreasonable product executive) UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Critical flaws in product requirements (tough and unreasonable product executive)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_REQUIREMENTS}} - - -GOAL -Produce a high-quality deliverable for: Critical flaws in product requirements (tough and unreasonable product executive). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Critique `{{PRODUCT_REQUIREMENTS}}` as a tough, skeptical product executive. -- Identify flaws in cross-team ownership, conflicting requirements, maintainability, strategic implications, clarity, and feasibility. -- Provide a detailed critique for each major section or point. -- End with a concise overall assessment emphasizing the most critical risks and likely impact. - -FORMAT -Return exactly this structure: - - -
[Name or number of the section you're critiquing]
-[Describe the specific issue you've identified] -[Explain the potential negative impact of this issue] -[If applicable, provide a suggestion for improvement, but make it sound reluctant and skeptical] - - - -[Final paragraph summarizing the most critical issues and their impact] - - -FAILURE -- `` sections are missing, malformed, or not tied to specific requirement sections. -- `` is missing or lacks a clear summary of top risks. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/ctas-from-copywriting-strategies/SKILL.md b/.claude/skills/ctas-from-copywriting-strategies/SKILL.md deleted file mode 100644 index 59ac8680..00000000 --- a/.claude/skills/ctas-from-copywriting-strategies/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: ctas-from-copywriting-strategies -description: >- - CTAs from copywriting strategies. Use when the user needs a product workflow for design & - prototyping related to ctas from copywriting strategies. Trigger terms: pm, marketing, cta. ---- - - - -# CTAs from copywriting strategies - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ctas-from-copywriting-strategies` -- **Lifecycle**: Design -- **Category**: Marketing -- **Primary artifact**: CTAs from copywriting strategies UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **CTAs from copywriting strategies**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT}} - - -GOAL -Generate 12 high-quality CTA options for `PRODUCT`, organized by 4 copywriting strategies. -Success metric: -- Exactly 12 CTAs are provided (3 per strategy). -- Every CTA follows length constraints and includes character count. -- CTA wording is specific to `PRODUCT` and non-duplicative. - -CONSTRAINTS -- Use only `PRODUCT` as input context. -- Create exactly 12 unique CTAs: 3 for each strategy. -- Use these strategy groups exactly: - - Match the feeling - - Actionable next step - - Handle the objection - - Make it specific -- Each CTA must be 6-35 characters (including spaces). -- Target average CTA length around 25 characters across all 12. -- Keep wording product-specific and action-oriented; avoid generic placeholders. -- Include character count after every CTA. - -FORMAT -Return exactly this structure: - - -1. Match the feeling - a. [CTA] (XX characters) - b. [CTA] (XX characters) - c. [CTA] (XX characters) - -2. Actionable next step - a. [CTA] (XX characters) - b. [CTA] (XX characters) - c. [CTA] (XX characters) - -3. Handle the objection - a. [CTA] (XX characters) - b. [CTA] (XX characters) - c. [CTA] (XX characters) - -4. Make it specific - a. [CTA] (XX characters) - b. [CTA] (XX characters) - c. [CTA] (XX characters) - - -FAILURE -- Not exactly 12 CTAs, or not exactly 3 per strategy group. -- Any CTA is outside 6-35 characters, or character counts are missing/incorrect. -- CTAs are repetitive, generic, or not tailored to `PRODUCT`. -- Required output schema/order is missing or malformed. diff --git a/.claude/skills/customer-insights-extraction-from-interview-transcript-using/SKILL.md b/.claude/skills/customer-insights-extraction-from-interview-transcript-using/SKILL.md deleted file mode 100644 index 8c085c19..00000000 --- a/.claude/skills/customer-insights-extraction-from-interview-transcript-using/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: customer-insights-extraction-from-interview-transcript-using -description: >- - Customer insights extraction from interview transcript using JTBD framework. Use when the - user needs a product workflow for user research related to customer insights extraction from - interview transcript using jtbd framework. Trigger terms: user-research, interviews, jtbd. ---- - - - -# Customer insights extraction from interview transcript using JTBD framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `customer-insights-extraction-from-interview-transcript-using` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Customer insights extraction from interview transcript using JTBD framework research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Customer insights extraction from interview transcript using JTBD framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INTERVIEW_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Customer insights extraction from interview transcript using JTBD framework. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{INTERVIEW_TRANSCRIPT}}` using JTBD forces: -- Pushes. -- Pulls. -- Habits. -- Anxieties. -- Extract force statements with required phrasing: -- Pushes and Habits as `When...` statements. -- Pulls as `So I can...` / `So I don't...` statements. -- Anxieties as concerns/questions. -- Synthesize decision dynamics including: -- Decision criteria. -- Trade-offs interviewee accepts. -- Functional, social, and emotional priorities. -- Ground all outputs in transcript evidence and state assumptions only when necessary. - -FORMAT -Return exactly this structure: - - - -[Briefly describe the interviewee's current situation, job, and challenges] - - - -[List the identified "When..." statements for Pushes] - - - -[List the identified "So I can..." or "So I don't..." statements for Pulls] - - - -[List the identified "When..." statements for Habits] - - - -[List the identified questions or statements of concern for Anxieties] - - - -[Provide a summary of your insights about the interviewee's decision-making process] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- JTBD force phrasing rules are not followed (`When...`, `So I can.../So I don't...`, anxiety concerns). -- Insights do not cover decision criteria, trade-offs, and functional/social/emotional drivers. -- Statements are generic or not grounded in transcript evidence. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/customer-journey-map-based-on-user-behavior-data/SKILL.md b/.claude/skills/customer-journey-map-based-on-user-behavior-data/SKILL.md deleted file mode 100644 index 50e07b44..00000000 --- a/.claude/skills/customer-journey-map-based-on-user-behavior-data/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: customer-journey-map-based-on-user-behavior-data -description: >- - Customer journey map based on user behavior data. Use when the user needs a product workflow - for business analysis related to customer journey map based on user behavior data. Trigger - terms: pm, business-analysis, customer-journey, analytics, research. ---- - - - -# Customer journey map based on user behavior data - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `customer-journey-map-based-on-user-behavior-data` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Customer journey map based on user behavior data analytics diagnosis with metric readout, caveats, decision, and next instrumented step - -Use this skill to run the Productize prompt contract for **Customer journey map based on user behavior data**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_BEHAVIOR_DATA}} - - -GOAL -Produce a high-quality deliverable for: Customer journey map based on user behavior data. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Identify stages in chronological order and include key touchpoints + decision moments per stage. -- Quantify time spent per stage; if unavailable, provide an estimate and label it as an assumption. -- Highlight friction points and delight points with supporting signals/metrics where available. -- Map emotional states to interactions using observed behavior, sentiment, or explicit feedback signals. -- Include corresponding metrics per stage (for example: conversion, engagement, abandonment, CSAT/NPS, retention proxies). -- Keep insights specific and actionable. - - -FORMAT -Return exactly this structure: - - - -[Stage Name] -[List key touchpoints and decision moments] -[Average time spent] -[Identified friction points] -[Identified delight points] -[Inferred emotional state] -[Relevant metrics with values] - -[Repeat the structure for each identified stage in the journey] - - - -[Brief summary of key insights, notable trends, major pain points, and opportunity areas] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/data-context-extractor/SKILL.md b/.claude/skills/data-context-extractor/SKILL.md deleted file mode 100644 index e4c5211f..00000000 --- a/.claude/skills/data-context-extractor/SKILL.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -name: data-context-extractor -description: >- - Generate or improve a company-specific data analysis skill by extracting tribal knowledge - from analysts. Use to bootstrap warehouse context, document schemas and metrics, or update - an existing data skill with tables, terminology, filters, and query patterns. ---- - - - -# Data Context Extractor - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `data-context-extractor` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Data Context Extractor analytics diagnosis with metric readout, caveats, decision, and next instrumented step - -Create or improve a company-specific data analysis skill by extracting warehouse knowledge from analysts. - -## Modes - -### Bootstrap Mode - -Use when the user wants a new data context skill for a warehouse. - -Triggers include: -- "Create a data context skill" -- "Set up data analysis for our warehouse" -- "Help me create a skill for our database" -- "Generate a data skill for [company]" - -### Iteration Mode - -Use when the user has an existing skill and wants to add context. - -Triggers include: -- "Add context about [domain]" -- "The skill needs more info about [topic]" -- "Update the data skill with [metrics/tables/terminology]" -- "Improve the [domain] reference" - -## Bootstrap Workflow - -### 1. Identify Warehouse - -Ask what warehouse is used: BigQuery, Snowflake, PostgreSQL/Redshift, Databricks, or another system. Check available MCP or connector tools before assuming. - -### 2. Explore Schema - -Use connected data tools to: -- List datasets, schemas, or databases. -- Identify the 3-5 most queried tables. -- Pull schema details for key tables. - -If tools are not connected, ask the analyst for schema exports, table samples, or representative queries. - -### 3. Extract Tribal Knowledge - -Ask conversationally: -- Entity disambiguation: what do "user", "customer", "account", and "organization" mean here? -- Primary identifiers: what IDs matter, and which are stable? -- Key metrics: top 2-3 metrics, exact formulas, tables, time windows, caveats. -- Data hygiene: filters that must always be applied. -- Gotchas: timezone issues, null behavior, snapshots vs current state, misleading column names. - -### 4. Generate Skill - -Create: - -```text -[company]-data-analyst/ -โ”œโ”€โ”€ SKILL.md -โ””โ”€โ”€ references/ - โ”œโ”€โ”€ entities.md - โ”œโ”€โ”€ metrics.md - โ”œโ”€โ”€ tables/ - โ”‚ โ”œโ”€โ”€ [domain].md - โ”‚ โ””โ”€โ”€ ... - โ””โ”€โ”€ dashboards.json -``` - -The generated SKILL.md should include: -- Frontmatter with name and description. -- When to use the skill. -- Warehouse dialect notes. Load `references/sql-dialects.md` and include only the matching warehouse section. -- Knowledge base navigation. -- Query safety and validation rules. -- Instructions to load only relevant reference files. - -Use `references/skill-template.md` as the starting structure for the generated `SKILL.md`. Remove unused sections and replace every placeholder before delivery. - -If unsure what "good" looks like, load `references/example-generated-skill.md` as a fictional quality example. Do not copy ShopCo-specific details into real customer skills. - -### 5. Package Skill - -When the user wants a distributable archive, run the bundled packager: - -```bash -python scripts/package_data_skill.py /path/to/[company]-data-analyst /path/to/output-dir -``` - -The script validates the generated skill and writes a `.skill` zip archive that can be shared or installed elsewhere. - -## Iteration Workflow - -1. Locate or ask for the existing skill folder or zip. -2. Read SKILL.md and references to understand current coverage. -3. Ask what domain, metric, table, or terminology is missing. -4. Explore relevant tables or ask targeted analyst questions. -5. Add or update the relevant reference file. -6. Update SKILL.md navigation. -7. Repackage with `scripts/package_data_skill.py` when the user needs a distributable archive, or summarize changed files when they only need local edits. - -## Reference Standards - -Table docs include location, description, primary key, update frequency, key columns, relationships, sample queries, and gotchas. - -Metric docs include name, definition, formula, source tables, filters, caveats, and examples. - -Entity docs include definition, primary table, ID fields, relationships, standard filters, and terminology notes. - -Use `references/domain-template.md` when creating domain reference files under `references/tables/`. - -## Quality Checklist - -- SKILL.md has valid name and description. -- Entity definitions are unambiguous. -- Metric formulas are exact. -- Standard exclusions are documented. -- SQL dialect is named. -- Each domain has sample queries. -- Reference files are linked from SKILL.md. diff --git a/.claude/skills/data-context-extractor/references/domain-template.md b/.claude/skills/data-context-extractor/references/domain-template.md deleted file mode 100644 index 21663a87..00000000 --- a/.claude/skills/data-context-extractor/references/domain-template.md +++ /dev/null @@ -1,136 +0,0 @@ -# Domain Reference File Template - -Use this template when creating reference files for specific data domains such as revenue, users, marketing, product usage, sales, or support. - -````markdown -# [DOMAIN_NAME] Tables - -This document contains [domain]-related tables, metrics, and query patterns. - -## Quick Reference - -### Business Context - -[2-3 sentences explaining what this domain covers and key concepts] - -### Entity Clarification - -**"[AMBIGUOUS_TERM]" can mean:** -- **[MEANING_1]**: [DEFINITION] (`[TABLE]`: `[ID_FIELD]`) -- **[MEANING_2]**: [DEFINITION] (`[TABLE]`: `[ID_FIELD]`) - -Always clarify which one before querying. - -### Standard Filters - -For [domain] queries, always: - -```sql -WHERE [STANDARD_FILTER_1] - AND [STANDARD_FILTER_2] -``` - -## Key Tables - -### [TABLE_1_NAME] - -**Location**: `[project.dataset.table]` or `[schema.table]` -**Description**: [What this table contains, when to use it] -**Primary Key**: [COLUMN(S)] -**Update Frequency**: [Daily/Hourly/Real-time] ([LAG] lag) -**Partitioned By**: [PARTITION_COLUMN] (if applicable) - -| Column | Type | Description | Notes | -|---|---|---|---| -| `[column_1]` | [TYPE] | [DESCRIPTION] | [GOTCHA_OR_CONTEXT] | -| `[column_2]` | [TYPE] | [DESCRIPTION] | | -| `[column_3]` | [TYPE] | [DESCRIPTION] | Nullable | - -**Relationships**: -- Joins to `[OTHER_TABLE]` on `[JOIN_KEY]` -- Parent of `[CHILD_TABLE]` via `[FOREIGN_KEY]` - -**Nested/Struct Fields** (if applicable): -- `[struct_name].[field_1]`: [DESCRIPTION] -- `[struct_name].[field_2]`: [DESCRIPTION] - -### [TABLE_2_NAME] - -[Repeat the table format above.] - -## Key Metrics - -| Metric | Definition | Table | Formula | Notes | -|---|---|---|---|---| -| [METRIC_1] | [DEFINITION] | [TABLE] | `[FORMULA]` | [CAVEATS] | -| [METRIC_2] | [DEFINITION] | [TABLE] | `[FORMULA]` | | - -## Sample Queries - -### [QUERY_PURPOSE_1] - -```sql --- [Brief description of what this query does] -SELECT - [columns] -FROM [table] -WHERE [standard_filters] -GROUP BY [grouping] -ORDER BY [ordering]; -``` - -### [QUERY_PURPOSE_2] - -```sql -[ANOTHER_COMMON_QUERY] -``` - -### [QUERY_PURPOSE_3]: [More Complex Pattern] - -```sql -WITH [cte_name] AS ( - [CTE_LOGIC] -) -SELECT - [final_columns] -FROM [cte_name] -[joins_and_filters]; -``` - -## Common Gotchas - -1. **[GOTCHA_1]**: [EXPLANATION] - - Wrong: `[INCORRECT_APPROACH]` - - Right: `[CORRECT_APPROACH]` - -2. **[GOTCHA_2]**: [EXPLANATION] - -## Related Dashboards - -| Dashboard | Link | Use For | -|---|---|---| -| [DASHBOARD_1] | [URL] | [DESCRIPTION] | -| [DASHBOARD_2] | [URL] | [DESCRIPTION] | -```` - -## Tips for Creating Domain Files - -1. Start with the most-queried tables. Do not document everything. -2. Include column-level detail only for important columns. Skip obvious columns unless there is a gotcha. -3. Prefer real query examples over abstract descriptions. -4. Document gotchas prominently. -5. Keep sample queries runnable with real table and column names. -6. Note nested, struct, JSON, and array fields explicitly. -7. Remove unused sections, such as related dashboards, if there is no useful content. - -## Suggested Domain Files - -Common domains to document: - -- `revenue.md`: billing, subscriptions, ARR, transactions. -- `users.md`: accounts, authentication, user attributes. -- `product.md`: feature usage, events, sessions. -- `growth.md`: DAU/WAU/MAU, retention, activation. -- `sales.md`: CRM, pipeline, opportunities. -- `marketing.md`: campaigns, attribution, leads. -- `support.md`: tickets, CSAT, response times. diff --git a/.claude/skills/data-context-extractor/references/example-generated-skill.md b/.claude/skills/data-context-extractor/references/example-generated-skill.md deleted file mode 100644 index 83296bfe..00000000 --- a/.claude/skills/data-context-extractor/references/example-generated-skill.md +++ /dev/null @@ -1,191 +0,0 @@ -# Example Generated Skill - -This is a fictional example of what a generated company-specific data analysis skill can look like after the bootstrap process. Use it as a quality reference, not as source data to copy into real customer skills. - -The example company is "ShopCo", a fictional e-commerce company using Snowflake. - -## Example SKILL.md - -````markdown ---- -name: shopco-data-analyst -description: >- - ShopCo data analysis skill for Snowflake. Provides context for querying e-commerce data - including customer, order, and product analytics. Use when analyzing ShopCo data for revenue - and order metrics, customer behavior and retention, product performance, or any data questions - requiring ShopCo-specific context. ---- - -# ShopCo Data Analysis - -## SQL Dialect: Snowflake - -- **Table references**: `SHOPCO_DW.SCHEMA.TABLE`; quoted identifiers are case-sensitive -- **Safe division**: `DIV0(a, b)` returns 0; `DIV0NULL(a, b)` returns NULL -- **Date functions**: - - `DATE_TRUNC('MONTH', date_col)` - - `DATEADD(DAY, -1, date_col)` - - `DATEDIFF(DAY, start_date, end_date)` -- **Column exclusion**: `SELECT * EXCLUDE (column_to_exclude)` - -## Entity Disambiguation - -**"Customer" can mean:** -- **User**: A login account that can browse and save items (`CORE.DIM_USERS`: `user_id`) -- **Customer**: A user who has made at least one purchase (`CORE.DIM_CUSTOMERS`: `customer_id`) -- **Account**: A billing entity that can have multiple users in B2B (`CORE.DIM_ACCOUNTS`: `account_id`) - -**Relationships:** -- User -> Customer: 1:1 (`customer_id = user_id` for purchasers) -- Account -> User: 1:many (join on `account_id`) - -## Business Terminology - -| Term | Definition | Notes | -|---|---|---| -| GMV | Gross Merchandise Value: total order value before returns and discounts | Use for top-line reporting | -| NMV | Net Merchandise Value: GMV minus returns and discounts | Use for actual revenue | -| AOV | Average Order Value: NMV / order count | Exclude zero-dollar orders | -| LTV | Lifetime Value: total NMV per customer since first order | Rolling calculation, updates daily | -| CAC | Customer Acquisition Cost: marketing spend / new customers | Usually analyzed by cohort month | - -## Standard Filters - -Always apply these filters unless explicitly told otherwise: - -```sql --- Exclude test and internal orders -WHERE order_status != 'TEST' - AND customer_type != 'INTERNAL' - AND is_employee_order = FALSE - --- Exclude cancelled orders for revenue metrics - AND order_status NOT IN ('CANCELLED', 'FRAUDULENT') -``` - -## Key Metrics - -### Gross Merchandise Value (GMV) - -- **Definition**: Total value of all orders placed -- **Formula**: `SUM(order_total_gross)` -- **Source**: `CORE.FCT_ORDERS.order_total_gross` -- **Time grain**: Daily, aggregated to weekly/monthly -- **Caveats**: Includes orders that may later be cancelled or returned - -### Net Revenue - -- **Definition**: Actual revenue after returns and discounts -- **Formula**: `SUM(order_total_gross - return_amount - discount_amount)` -- **Source**: `CORE.FCT_ORDERS` -- **Caveats**: Returns can occur up to 90 days post-order; use settled revenue for finalized numbers - -## Knowledge Base Navigation - -| Domain | Reference File | Use For | -|---|---|---| -| Orders | `references/tables/orders.md` | Order tables, GMV/NMV calculations | -| Customers | `references/tables/customers.md` | User/customer entities, LTV, cohorts | -| Products | `references/tables/products.md` | Catalog, inventory, categories | -| Entities | `references/entities.md` | Entity definitions and relationships | -| Metrics | `references/metrics.md` | KPI calculations and formulas | - -## Common Query Patterns - -### Daily GMV by Channel - -```sql -SELECT - DATE_TRUNC('DAY', order_timestamp) AS order_date, - channel, - SUM(order_total_gross) AS gmv, - COUNT(DISTINCT order_id) AS order_count -FROM SHOPCO_DW.CORE.FCT_ORDERS -WHERE order_status NOT IN ('TEST', 'CANCELLED', 'FRAUDULENT') - AND order_timestamp >= DATEADD(DAY, -30, CURRENT_DATE()) -GROUP BY 1, 2 -ORDER BY 1 DESC, 3 DESC; -``` - -### Customer Cohort Retention - -```sql -WITH cohorts AS ( - SELECT - customer_id, - DATE_TRUNC('MONTH', first_order_date) AS cohort_month - FROM SHOPCO_DW.CORE.DIM_CUSTOMERS -) -SELECT - c.cohort_month, - DATEDIFF(MONTH, c.cohort_month, DATE_TRUNC('MONTH', o.order_timestamp)) AS months_since_first, - COUNT(DISTINCT c.customer_id) AS active_customers -FROM cohorts c -JOIN SHOPCO_DW.CORE.FCT_ORDERS o ON c.customer_id = o.customer_id -WHERE o.order_status NOT IN ('TEST', 'CANCELLED') -GROUP BY 1, 2 -ORDER BY 1, 2; -``` -```` - -## Example `references/tables/orders.md` - -````markdown -# Orders Tables - -Order and transaction data for ShopCo. - -## Key Tables - -### FCT_ORDERS - -**Location**: `SHOPCO_DW.CORE.FCT_ORDERS` -**Description**: Fact table of all orders. One row per order. -**Primary Key**: `order_id` -**Update Frequency**: Hourly with about 15 minutes of lag -**Partitioned By**: `order_date` - -| Column | Type | Description | Notes | -|---|---|---|---| -| `order_id` | VARCHAR | Unique order identifier | | -| `customer_id` | VARCHAR | Foreign key to `DIM_CUSTOMERS` | NULL for guest checkout | -| `order_timestamp` | TIMESTAMP_NTZ | When order was placed | UTC | -| `order_date` | DATE | Date portion of `order_timestamp` | Partition column | -| `order_status` | VARCHAR | Current status | PENDING, SHIPPED, DELIVERED, CANCELLED, RETURNED | -| `channel` | VARCHAR | Acquisition channel | WEB, APP, MARKETPLACE | -| `order_total_gross` | DECIMAL(12,2) | Pre-discount total | | -| `discount_amount` | DECIMAL(12,2) | Total discounts applied | | -| `return_amount` | DECIMAL(12,2) | Value of returned items | Updates async | - -**Relationships**: -- Joins to `DIM_CUSTOMERS` on `customer_id` -- Parent of `FCT_ORDER_ITEMS` via `order_id` - -## Sample Queries - -### Orders with Return Rate - -```sql -SELECT - DATE_TRUNC('WEEK', order_date) AS week, - COUNT(*) AS total_orders, - SUM(CASE WHEN return_amount > 0 THEN 1 ELSE 0 END) AS orders_with_returns, - DIV0(SUM(CASE WHEN return_amount > 0 THEN 1 ELSE 0 END), COUNT(*)) AS return_rate -FROM SHOPCO_DW.CORE.FCT_ORDERS -WHERE order_status NOT IN ('TEST', 'CANCELLED') - AND order_date >= DATEADD(MONTH, -3, CURRENT_DATE()) -GROUP BY 1 -ORDER BY 1; -``` -```` - -## What This Example Demonstrates - -- Complete frontmatter with a triggering description. -- Dialect-specific SQL notes. -- Clear entity disambiguation. -- Business terminology glossary. -- Standard filters as copy-paste SQL. -- Metric definitions with formulas and caveats. -- Navigation to reference files. -- Realistic, runnable query examples. diff --git a/.claude/skills/data-context-extractor/references/skill-template.md b/.claude/skills/data-context-extractor/references/skill-template.md deleted file mode 100644 index 03ea7c30..00000000 --- a/.claude/skills/data-context-extractor/references/skill-template.md +++ /dev/null @@ -1,144 +0,0 @@ -# Generated Skill Template - -Use this template when generating a new company-specific data analysis skill. Replace every placeholder before packaging or handing the skill to the user. - -````markdown ---- -name: [company]-data-analyst -description: >- - [COMPANY] data analysis skill. Provides context for querying [WAREHOUSE_TYPE], - including entity definitions, metric calculations, and common query patterns. - Use when analyzing [COMPANY] data for [PRIMARY_USE_CASE_1], [PRIMARY_USE_CASE_2], - [PRIMARY_USE_CASE_3], or any data question requiring [COMPANY]-specific context. ---- - -# [COMPANY] Data Analysis - -## SQL Dialect: [WAREHOUSE_TYPE] - -[INSERT THE MATCHING DIALECT SECTION FROM references/sql-dialects.md] - -## Entity Disambiguation - -When users mention these terms, clarify which entity they mean: - -**"User" can mean:** -- **Account**: An individual login/profile (`[PRIMARY_TABLE]`: `[ID_FIELD]`) -- **Organization**: A billing entity that can have multiple accounts (`[ORG_TABLE]`: `[ORG_ID]`) -- **[OTHER_TYPE]**: [DEFINITION] (`[TABLE]`: `[ID]`) - -**Relationships:** -- [ENTITY_1] -> [ENTITY_2]: [RELATIONSHIP_TYPE] (join on `[JOIN_KEY]`) - -## Business Terminology - -| Term | Definition | Notes | -|---|---|---| -| [TERM_1] | [DEFINITION] | [CONTEXT/GOTCHA] | -| [TERM_2] | [DEFINITION] | [CONTEXT/GOTCHA] | -| [ACRONYM] | [FULL_NAME] - [EXPLANATION] | | - -## Standard Filters - -Always apply these filters unless explicitly told otherwise: - -```sql --- Exclude test/internal data -WHERE [TEST_FLAG_COLUMN] = FALSE - AND [INTERNAL_FLAG_COLUMN] = FALSE - --- Exclude invalid/fraud - AND [STATUS_COLUMN] != '[EXCLUDED_STATUS]' - --- [OTHER STANDARD EXCLUSIONS] -``` - -**When to override:** -- [SCENARIO_1]: Include [NORMALLY_EXCLUDED] when [CONDITION] - -## Key Metrics - -### [METRIC_1_NAME] - -- **Definition**: [PLAIN_ENGLISH_EXPLANATION] -- **Formula**: `[EXACT_CALCULATION]` -- **Source**: `[TABLE_NAME].[COLUMN_NAME]` -- **Time grain**: [DAILY/WEEKLY/MONTHLY] -- **Caveats**: [EDGE_CASES_OR_GOTCHAS] - -### [METRIC_2_NAME] - -- **Definition**: [PLAIN_ENGLISH_EXPLANATION] -- **Formula**: `[EXACT_CALCULATION]` -- **Source**: `[TABLE_NAME].[COLUMN_NAME]` -- **Time grain**: [DAILY/WEEKLY/MONTHLY] -- **Caveats**: [EDGE_CASES_OR_GOTCHAS] - -## Data Freshness - -| Table | Update Frequency | Typical Lag | -|---|---|---| -| [TABLE_1] | [FREQUENCY] | [LAG] | -| [TABLE_2] | [FREQUENCY] | [LAG] | - -To check data freshness: - -```sql -SELECT MAX([DATE_COLUMN]) AS latest_data -FROM [TABLE]; -``` - -## Knowledge Base Navigation - -Use these reference files for detailed table documentation: - -| Domain | Reference File | Use For | -|---|---|---| -| [DOMAIN_1] | `references/tables/[domain1].md` | [BRIEF_DESCRIPTION] | -| [DOMAIN_2] | `references/tables/[domain2].md` | [BRIEF_DESCRIPTION] | -| Entities | `references/entities.md` | Entity definitions and relationships | -| Metrics | `references/metrics.md` | KPI calculations and formulas | - -## Common Query Patterns - -### [PATTERN_1_NAME] - -```sql -[SAMPLE_QUERY] -``` - -### [PATTERN_2_NAME] - -```sql -[SAMPLE_QUERY] -``` - -## Troubleshooting - -### Common Mistakes - -- **[MISTAKE_1]**: [EXPLANATION] -> [CORRECT_APPROACH] -- **[MISTAKE_2]**: [EXPLANATION] -> [CORRECT_APPROACH] - -### Access Issues - -- If you encounter permission errors on `[TABLE]`: [WORKAROUND] -- For PII-restricted columns: [ALTERNATIVE_APPROACH] - -### Performance Tips - -- Filter by `[PARTITION_COLUMN]` first to reduce data scanned. -- For large tables, use `LIMIT` during exploration. -- Prefer `[AGGREGATED_TABLE]` over `[RAW_TABLE]` when possible. -```` - -## Customization Notes - -When generating a skill: - -1. Fill all placeholders. Do not leave `[PLACEHOLDER]`, `[COMPANY]`, or other bracketed template text in the final skill. -2. Remove unused sections. -3. Replace generic advice with specific table names, column names, values, and warehouse behavior. -4. Include real sample queries using actual table and column names. -5. Keep the result scannable with tables, bullets, and code blocks. -6. Confirm `SKILL.md` has only valid skill frontmatter plus the Markdown body. diff --git a/.claude/skills/data-context-extractor/references/sql-dialects.md b/.claude/skills/data-context-extractor/references/sql-dialects.md deleted file mode 100644 index 50ffa3c3..00000000 --- a/.claude/skills/data-context-extractor/references/sql-dialects.md +++ /dev/null @@ -1,109 +0,0 @@ -# SQL Dialect Reference - -Use this reference when generating a company-specific data analysis skill. Include only the section that matches the user's warehouse. Do not paste every dialect into the generated skill. - -## BigQuery - -```markdown -## SQL Dialect: BigQuery - -- **Table references**: Use backticks: `project.dataset.table` -- **Safe division**: `SAFE_DIVIDE(a, b)` returns NULL instead of error -- **Date functions**: - - `DATE_TRUNC(date_col, MONTH)` - - `DATE_SUB(date_col, INTERVAL 1 DAY)` - - `DATE_DIFF(end_date, start_date, DAY)` -- **Column exclusion**: `SELECT * EXCEPT(column_to_exclude)` -- **Arrays**: `UNNEST(array_column)` to flatten -- **Structs**: Access with dot notation: `struct_col.field_name` -- **Timestamps**: `TIMESTAMP_TRUNC()`; timestamps are UTC by default -- **String matching**: `LIKE`, `REGEXP_CONTAINS(col, r'pattern')` -- **NULLs in aggregations**: Most functions ignore NULLs; use `IFNULL()` or `COALESCE()` -``` - -## Snowflake - -```markdown -## SQL Dialect: Snowflake - -- **Table references**: `DATABASE.SCHEMA.TABLE`; quoted identifiers are case-sensitive -- **Safe division**: `DIV0(a, b)` returns 0; `DIV0NULL(a, b)` returns NULL -- **Date functions**: - - `DATE_TRUNC('MONTH', date_col)` - - `DATEADD(DAY, -1, date_col)` - - `DATEDIFF(DAY, start_date, end_date)` -- **Column exclusion**: `SELECT * EXCLUDE (column_to_exclude)` -- **Arrays**: `FLATTEN(array_column)` to flatten; access with `value` -- **Variants/JSON**: Access with colon notation: `variant_col:field_name` -- **Timestamps**: `TIMESTAMP_NTZ` has no timezone; `TIMESTAMP_TZ` includes timezone -- **String matching**: `LIKE`, `REGEXP_LIKE(col, 'pattern')` -- **Case sensitivity**: Identifiers are uppercase by default unless quoted -``` - -## PostgreSQL / Redshift - -```markdown -## SQL Dialect: PostgreSQL/Redshift - -- **Table references**: `schema.table` using lowercase naming by convention -- **Safe division**: Use `NULLIF`: `a / NULLIF(b, 0)` -- **Date functions**: - - `DATE_TRUNC('month', date_col)` - - `date_col - INTERVAL '1 day'` - - `DATE_PART('day', end_date - start_date)` -- **Column selection**: No `EXCEPT`; list columns explicitly -- **Arrays**: `UNNEST(array_column)` in PostgreSQL; limited support in Redshift -- **JSON**: `json_col->>'field_name'` for text; `json_col->'field_name'` for JSON -- **Timestamps**: `AT TIME ZONE 'UTC'` for timezone conversion -- **String matching**: `LIKE`; `col ~ 'pattern'` for regex -- **Boolean**: Native `BOOLEAN`; use `TRUE` and `FALSE` -``` - -## Databricks / Spark SQL - -```markdown -## SQL Dialect: Databricks/Spark SQL - -- **Table references**: `catalog.schema.table` with Unity Catalog, or `schema.table` -- **Safe division**: Use `TRY_DIVIDE(a, b)` or `a / NULLIF(b, 0)` -- **Date functions**: - - `DATE_TRUNC('MONTH', date_col)` - - `DATE_SUB(date_col, 1)` - - `DATEDIFF(end_date, start_date)` -- **Column exclusion**: `SELECT * EXCEPT (column_to_exclude)` in Databricks SQL -- **Arrays**: `EXPLODE(array_column)` to flatten -- **Structs**: Access with dot notation: `struct_col.field_name` -- **JSON**: `json_col:field_name` or `GET_JSON_OBJECT()` -- **String matching**: `LIKE`; `RLIKE` for regex -- **Delta features**: `DESCRIBE HISTORY`; time travel with `VERSION AS OF` -``` - -## MySQL - -```markdown -## SQL Dialect: MySQL - -- **Table references**: Use backticks for reserved words or special names: `database`.`table` -- **Safe division**: `IF(b = 0, NULL, a / b)` or `a / NULLIF(b, 0)` -- **Date functions**: - - `DATE_FORMAT(date_col, '%Y-%m-01')` for month truncation - - `DATE_SUB(date_col, INTERVAL 1 DAY)` - - `DATEDIFF(end_date, start_date)` -- **Column selection**: No `EXCEPT`; list columns explicitly -- **Arrays**: Limited native support; often stored as JSON -- **JSON**: `JSON_EXTRACT(col, '$.field')` or `col->>'$.field'` -- **Timestamps**: `CONVERT_TZ()` for timezone conversion -- **String matching**: `LIKE`; `REGEXP` for regex -- **Case sensitivity**: Table names are case-sensitive on Linux, not on Windows -``` - -## Common Patterns Across Dialects - -| Operation | BigQuery | Snowflake | PostgreSQL | Databricks | -|---|---|---|---|---| -| Current date | `CURRENT_DATE()` | `CURRENT_DATE()` | `CURRENT_DATE` | `CURRENT_DATE()` | -| Current timestamp | `CURRENT_TIMESTAMP()` | `CURRENT_TIMESTAMP()` | `NOW()` | `CURRENT_TIMESTAMP()` | -| String concat | `CONCAT()` or `||` | `CONCAT()` or `||` | `CONCAT()` or `||` | `CONCAT()` or `||` | -| Coalesce | `COALESCE()` | `COALESCE()` | `COALESCE()` | `COALESCE()` | -| Case when | `CASE WHEN` | `CASE WHEN` | `CASE WHEN` | `CASE WHEN` | -| Count distinct | `COUNT(DISTINCT x)` | `COUNT(DISTINCT x)` | `COUNT(DISTINCT x)` | `COUNT(DISTINCT x)` | diff --git a/.claude/skills/data-context-extractor/references/tables/README.md b/.claude/skills/data-context-extractor/references/tables/README.md deleted file mode 100644 index 15f885a7..00000000 --- a/.claude/skills/data-context-extractor/references/tables/README.md +++ /dev/null @@ -1,3 +0,0 @@ -# Generated Table References - -Company-specific data skills can add generated table-domain files in this directory. diff --git a/.claude/skills/data-context-extractor/scripts/package_data_skill.py b/.claude/skills/data-context-extractor/scripts/package_data_skill.py deleted file mode 100755 index d934198e..00000000 --- a/.claude/skills/data-context-extractor/scripts/package_data_skill.py +++ /dev/null @@ -1,145 +0,0 @@ -#!/usr/bin/env python3 -""" -Package a generated data analysis skill into a distributable .skill archive. - -The .skill file is a zip archive that keeps the skill folder as the top-level -directory, for example: - - acme-data-analyst.skill - โ””โ”€โ”€ acme-data-analyst/ - โ”œโ”€โ”€ SKILL.md - โ””โ”€โ”€ references/ - -Usage: - python package_data_skill.py [output-directory] - -Examples: - python package_data_skill.py /tmp/acme-data-analyst - python package_data_skill.py /tmp/acme-data-analyst /tmp/outputs -""" - -from __future__ import annotations - -import sys -import zipfile -from pathlib import Path - - -JUNK_NAMES = {"__pycache__", ".DS_Store", "Thumbs.db"} - - -def validate_skill(skill_path: Path) -> tuple[bool, str]: - """Validate the minimum skill structure before packaging.""" - - skill_md = skill_path / "SKILL.md" - if not skill_md.exists(): - return False, "Missing SKILL.md" - - content = skill_md.read_text(encoding="utf-8") - if not content.startswith("---\n"): - return False, "SKILL.md missing YAML frontmatter" - - end = content.find("\n---", 4) - if end == -1: - return False, "SKILL.md frontmatter is not closed" - - frontmatter = content[:end] - if "name:" not in frontmatter: - return False, "SKILL.md missing 'name' in frontmatter" - if "description:" not in frontmatter: - return False, "SKILL.md missing 'description' in frontmatter" - - placeholders = ["[PLACEHOLDER]", "[COMPANY]", "{{", "}}"] - for placeholder in placeholders: - if placeholder in content: - return False, f"SKILL.md contains unfilled placeholder text: {placeholder}" - - return True, "Validation passed" - - -def should_skip(file_path: Path, skill_path: Path, output_file: Path) -> bool: - """Return True for junk files or files that should not be packaged.""" - - if file_path.resolve() == output_file.resolve(): - return True - - relative_parts = file_path.relative_to(skill_path).parts - if any(part.startswith(".") for part in relative_parts): - return True - if any(part in JUNK_NAMES for part in relative_parts): - return True - - return False - - -def package_skill(skill_path_arg: str, output_dir_arg: str | None = None) -> Path | None: - """ - Package a skill folder into a .skill archive. - - Args: - skill_path_arg: Path to the skill folder. - output_dir_arg: Optional output directory. - - Returns: - Path to the created .skill file, or None if packaging failed. - """ - - skill_path = Path(skill_path_arg).expanduser().resolve() - - if not skill_path.exists(): - print(f"Error: skill folder not found: {skill_path}") - return None - - if not skill_path.is_dir(): - print(f"Error: path is not a directory: {skill_path}") - return None - - print("Validating skill...") - valid, message = validate_skill(skill_path) - if not valid: - print(f"Validation failed: {message}") - return None - print(f"{message}\n") - - output_dir = Path(output_dir_arg).expanduser().resolve() if output_dir_arg else Path.cwd() - output_dir.mkdir(parents=True, exist_ok=True) - output_file = output_dir / f"{skill_path.name}.skill" - - try: - with zipfile.ZipFile(output_file, "w", zipfile.ZIP_DEFLATED) as zip_file: - for file_path in sorted(skill_path.rglob("*")): - if not file_path.is_file(): - continue - if should_skip(file_path, skill_path, output_file): - continue - - archive_name = file_path.relative_to(skill_path.parent) - zip_file.write(file_path, archive_name) - print(f" Added: {archive_name}") - - print(f"\nPackaged skill: {output_file}") - return output_file - - except Exception as error: # noqa: BLE001 - command-line utility should report any failure. - print(f"Error creating skill archive: {error}") - return None - - -def main() -> int: - if len(sys.argv) < 2: - print(__doc__) - return 1 - - skill_path = sys.argv[1] - output_dir = sys.argv[2] if len(sys.argv) > 2 else None - - print(f"Packaging skill: {skill_path}") - if output_dir: - print(f"Output directory: {output_dir}") - print() - - return 0 if package_skill(skill_path, output_dir) else 1 - - -if __name__ == "__main__": - raise SystemExit(main()) diff --git a/.claude/skills/data-driven-research-plans-from-leadership-intuition/SKILL.md b/.claude/skills/data-driven-research-plans-from-leadership-intuition/SKILL.md deleted file mode 100644 index ae458721..00000000 --- a/.claude/skills/data-driven-research-plans-from-leadership-intuition/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: data-driven-research-plans-from-leadership-intuition -description: >- - Data-driven research plans from leadership intuition. Use when the user needs a product - workflow for user research related to data-driven research plans from leadership intuition. - Trigger terms: user-research, research-planning, product-strategy. ---- - - - -# Data-driven research plans from leadership intuition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `data-driven-research-plans-from-leadership-intuition` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Data-driven research plans from leadership intuition research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Data-driven research plans from leadership intuition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY_CONTEXT}} -- {{INTUITION}} - - -GOAL -Produce a high-quality deliverable for: Data-driven research plans from leadership intuition. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Convert `{{INTUITION}}` into an evidence-based research plan grounded in `{{COMPANY_CONTEXT}}`. -- Include: -- Intuition summary with explicit bias/assumption check. -- Prioritized key assumptions affecting feature success. -- 3-5 measurable research objectives tied to assumptions. -- Mixed quantitative + qualitative methods with rationale per objective. -- Validation/refutation success metrics aligned to business goals. -- Risks/challenges with mitigation strategies. -- Realistic milestone-based timeline. -- Keep analysis objective and decision-oriented (validate, refute, or partially support intuition). - -FORMAT -Return exactly this structure: - - -1. Executive Summary: [brief decision-oriented summary] -2. Analysis of Intuition: [key points + potential biases/assumptions] -3. Key Assumptions: [prioritized assumptions] -4. Research Objectives: [3-5 measurable objectives] -5. Research Methods: [mixed methods + why each fits] -6. Success Metrics: [clear validation/refutation thresholds] -7. Potential Challenges and Mitigation Strategies: [risk -> mitigation] -8. Proposed Timeline: [milestones and duration] -9. Conclusion: [how findings will inform go/no-go or iteration decisions] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Research objectives are not measurable or not tied to key assumptions. -- Methods do not include both quantitative and qualitative approaches (unless explicitly justified by context). -- Success metrics are vague and lack decision thresholds. -- Timeline lacks milestones or is not feasible for proposed methods. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/data-visualization/SKILL.md b/.claude/skills/data-visualization/SKILL.md deleted file mode 100644 index c606e04a..00000000 --- a/.claude/skills/data-visualization/SKILL.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -name: data-visualization -description: >- - Create effective data visualizations with Python using matplotlib, seaborn, and plotly. Use - when choosing chart types, building charts, creating publication-quality figures, or - applying visualization design principles like accessibility and color theory. ---- - - - -# Data Visualization - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `data-visualization` -- **Lifecycle**: Design -- **Category**: Analytics -- **Primary artifact**: Data Visualization UX/design review with findings, constraints, fixes, and acceptance checks - -Helper skill for chart selection, Python visualization patterns, design principles, and accessibility. - -## Invocation - -This is primarily a support skill for `analyze`, `create-viz`, `build-dashboard`, and `metrics-review`. Use it explicitly when chart-design guidance is needed. - -Use `visual-decision-making-review` instead when the user asks whether a chart, slide, -dashboard, canvas, or diagram may bias a decision, create overconfidence, hide alternatives, -or distort executive/stakeholder judgment. - -## Chart Selection - -Choose by data relationship: - -| Relationship | Best Chart | Alternatives | -|---|---|---| -| Trend over time | Line chart | Area chart | -| Category comparison | Bar chart | Horizontal bar, lollipop | -| Ranking | Horizontal bar | Dot plot, slope chart | -| Part-to-whole | Stacked bar | Treemap, waffle | -| Composition over time | Stacked area | 100 percent stacked bar | -| Distribution | Histogram | Box, violin, strip | -| Correlation | Scatter | Bubble chart | -| Correlation matrix | Heatmap | Pair plot | -| Geographic | Choropleth | Bubble map | -| Flow | Sankey | Funnel | -| Target performance | Bullet chart | Gauge only for one KPI | -| Many KPIs | Small multiples | Dashboard | - -Avoid: -- Pie charts unless fewer than six categories and rough proportion is enough. -- 3D charts. -- Dual-axis charts unless clearly labeled and justified. -- Stacked bars with many middle segments. - -## Python Patterns - -Use matplotlib + seaborn for static publication charts: - -```python -import matplotlib.pyplot as plt -import matplotlib.ticker as mticker -import seaborn as sns -import pandas as pd - -plt.style.use("seaborn-v0_8-whitegrid") -sns.set_palette("colorblind") -fig, ax = plt.subplots(figsize=(10, 6), dpi=150) -``` - -Use plotly for interactive charts: - -```python -import plotly.express as px -fig = px.line(df, x="date", y="value", color="category", title="Metric trend") -fig.update_layout(hovermode="x unified") -fig.write_html("interactive_chart.html") -``` - -Always include: -- Insight-led title. -- Axis labels and units. -- Proper number formatting. -- Data source and date range when known. -- Saved output file. - -## Design Principles - -Color: -- Use color to encode meaning, not decoration. -- Use a colorblind-friendly palette. -- Highlight the story and gray out context. -- Use sequential palettes for ordered values and diverging palettes around meaningful midpoints. - -Typography: -- Title states the insight. -- Subtitle provides scope, date range, or filters. -- Labels are readable. -- Data labels are used only when they add clarity. - -Layout: -- Remove chart junk. -- Sort categories by value unless natural order matters. -- Use consistent scales across small multiples. -- Give the chart enough whitespace. - -Accuracy: -- Bar charts start at zero. -- Do not hide axis breaks. -- Show uncertainty when relevant. -- Do not overstate precision. - -## Accessibility Checklist - -- Chart works without relying on color alone. -- Text is readable at standard zoom. -- Title describes the insight. -- Axes include units. -- Legend is clear and unobtrusive. -- Data source and date range are noted. -- Provide a table alternative when possible. diff --git a/.claude/skills/decision-making-with-the-gut-check-protocol/SKILL.md b/.claude/skills/decision-making-with-the-gut-check-protocol/SKILL.md deleted file mode 100644 index f098239f..00000000 --- a/.claude/skills/decision-making-with-the-gut-check-protocol/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: decision-making-with-the-gut-check-protocol -description: >- - Decision-making with the GUT CHECK protocol. Use when the user needs a product workflow for - decision making related to decision-making with the gut check protocol. Trigger terms: - decision-making, self-reflection, frameworks, coaching. ---- - - - -# Decision-making with the GUT CHECK protocol - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `decision-making-with-the-gut-check-protocol` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: GUT CHECK decision reflection with pressures, risks, values, timing, red flags, and recommendation - -Use this skill to run the Productize prompt contract for **Decision-making with the GUT CHECK protocol**. - -## Decision-Making Boundary - -Use this skill for reflective, pressure-aware decision making when the user needs to surface -gut signals, values, red flags, personal risk, timing, and hidden costs. - -Do not use it for strategic decision quality review, group decision process design, visual -decision review, role-identity decision mapping, or reusable innovation heuristics. Route -those to the dedicated decision-making skills. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DECISION}} - - -GOAL -Guide the user through the full GUT CHECK protocol for `DECISION`, then provide a grounded recommendation. -Success metric: -- Covers all 8 GUT CHECK stages with relevant reflective questions. -- Separates prompts/questions from interpretation clearly. -- Provides a summary and final recommendation consistent with the surfaced signals. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Cover all 8 protocol stages: - 1. Pause & Feel - 2. Identify Pressures - 3. Risk Assessment - 4. Competency Check - 5. Values Alignment - 6. Timing Check - 7. Red Flags - 8. Final Gut Check -- For each stage, provide concise reflection prompts tailored to `DECISION`. -- Keep tone supportive, neutral, and non-judgmental. -- If user responses are not available, mark insights as provisional and identify what responses are needed. -- Include the pressure mantra and key protocol reminders. -- Final recommendation must align with surfaced signals (not generic advice). - -FORMAT -Return exactly this structure: - - -[Stage-specific prompts] -[Stage-specific prompts] -[Stage-specific prompts] -[Stage-specific prompts] -[Stage-specific prompts] -[Stage-specific prompts] -[Stage-specific prompts and pause rule] -[Stage-specific prompts] -"This is now. Whatever comes, I can handle it. Next step forward." -[Key points about gut/hidden costs/alternate paths/well-being] - - - -[Summary of user responses if provided; otherwise a provisional synthesis and missing-response checklist] - - - -[Provide a final recommendation based on the user's responses, explaining the reasoning behind it] - - -FAILURE -- Missing any required stage in ``, ``, or ``. -- Recommendation is generic or not supported by protocol signals. -- Tone is judgmental, coercive, or dismissive. -- Missing provisional labeling when user responses are unavailable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/decision-reversibility-classification-from-first-principles/SKILL.md b/.claude/skills/decision-reversibility-classification-from-first-principles/SKILL.md deleted file mode 100644 index 8b641e86..00000000 --- a/.claude/skills/decision-reversibility-classification-from-first-principles/SKILL.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -name: decision-reversibility-classification-from-first-principles -description: >- - Decision reversibility classification from first principles. Use when the user needs a - product workflow for decision making related to decision reversibility classification from - first principles. Trigger terms: pm, decision-making, reversibility, first-principles, - frameworks. ---- - - - -# Decision reversibility classification from first principles - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `decision-reversibility-classification-from-first-principles` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: Decision reversibility classification from first principles decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **Decision reversibility classification from first principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SITUATION}} -- {{DECISION}} - - -GOAL -Classify a decisionโ€™s reversibility from first principles as `Hat`, `Haircut`, or `Tattoo`, with explicit reasoning. -Success metric: -- Evaluates immediate and long-term consequences. -- Assesses reversal cost/time/resources and permanence. -- Produces a defensible classification with confidence and rationale. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required dimensions: - 1. Immediate consequences. - 2. Long-term effects on stakeholders/environment. - 3. Reversal effort/time/resource requirements. - 4. Permanent or hard-to-undo changes. -- Apply category definitions strictly: - - `Hat`: easily reversible; minimal lasting consequences. - - `Haircut`: reversible with meaningful but manageable cost/friction. - - `Tattoo`: largely irreversible or long-lasting structural impact. -- Consider multiple plausible outcomes; avoid single-path reasoning. -- Keep analysis neutral and grounded in `SITUATION` and `DECISION`. -- Explicitly label assumptions where context is incomplete. - -FORMAT -Return exactly this structure: - - -[Assessment] -[Assessment] -[Assessment of effort/time/resources] -[What becomes hard or impossible to undo] -[How the above dimensions combine into a final judgment] - - - -[Hat | Haircut | Tattoo] - - -[High | Medium | Low] - [Brief reason] - - -[If reversible, concise path to reverse/mitigate; if tattoo, explain why reversal is impractical] - - -FAILURE -- Required schema sections are missing or malformed. -- Classification is provided without first-principles reasoning across required dimensions. -- Category choice contradicts stated evidence. -- Analysis is generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/decision-rights-using-davci/SKILL.md b/.claude/skills/decision-rights-using-davci/SKILL.md deleted file mode 100644 index 4bec796b..00000000 --- a/.claude/skills/decision-rights-using-davci/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: decision-rights-using-davci -description: >- - Decision rights using DAVCI. Use when the user needs a product workflow for stakeholder - management related to decision rights using davci. Trigger terms: decision-rights, - product-ops, facilitation, governance, stakeholder-management. ---- - - - -# Decision rights using DAVCI - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `decision-rights-using-davci` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Decision rights using DAVCI stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Decision rights using DAVCI**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Decision rights using DAVCI. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Enforce DAVCI with hard rules: -- Exactly one `D` per decision. -- `A` is optional and cannot equal `D`. -- `V` is at most one person per domain (`Security`, `Legal`, `Privacy`, `Brand`, `Compliance`, `Other`) with a time-boxed window (default `48h` if missing). -- `C` and `I` use role names; keep `C <= 5`, `I <= 15`, and `C+I <= 20`. -- Every decision includes title, deadline (date + time), type, escalation, success test, and comms plan. -- Run rapid intake, split into 1-5 decision objects, assign DAVCI per object, and auto-correct rule violations immediately. -- Apply defaults when missing (`TBD` allowed), including fallback deadlines by urgency. -- For each decision object, output the exact DAVCI card fields plus a ready-to-send summary line. -- Handle edge cases (multi-team layering, multi-domain veto order, emergency windows, non-response, D handoff). -- Offer short follow-ups (calendar text, Slack draft, Jira/PR/design header snippet). - -FORMAT -Return exactly this structure: - -Kickoff: -Tell me the situation in 3-5 sentences and the hard deadline (date + time). Include the names/roles you think matter. I'll split it into the right decision objects and we'll assign DAVCI for each in under 30 minutes. - -Rapid intake questions: -1. [Question 1] -2. [Question 2] -3. [Question 3] -4. [Question 4] -5. [Question 5] -6. [Question 6] -7. [Question 7] -8. [Question 8] - -Decision objects: -- Object 1: [short name] - [why separate]; draft deadline [date/time] -- [Object 2..5 if needed] - -Decision: [short title] -Context: [1-2 short sentences] -Deadline: [date and time] -Type: [Strategy|Scope|Design|Technical|Process|Risk|Commercial|Other] -D: [name, role] -A: [name, role] or "None" -V: [Domain - name, window hours]; [Domain - name, window hours] -C: [role/name]; [role/name] -I: [role/name]; [role/name] -Escalation: [name, role] -Success test: [single checkable sentence] -Comms: [channels + audience + timing] -Notes/Risks: [short list if any] - -Decision summary: -Decision: [title]. D: [name]. Deadline: [date/time]. Veto windows: [domain - window]. Cs: [roles]. Escalation: [name]. Success test: [test]. Comms: [plan]. Reply with blockers within your window; otherwise we proceed. - -Follow-ups: -- [15-minute review calendar text offer] -- [Slack post draft offer] -- [Jira/PR/design header snippet offer] - -FAILURE -- DAVCI rule violations are not auto-corrected (`D` count, `A==D`, multi-holder veto domain, missing veto window, `C/I` caps). -- Missing required decision fields (deadline, type, escalation, success test, comms). -- Output does not include both DAVCI card(s) and decision summary line(s). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/defining-the-niche-from-user-input/SKILL.md b/.claude/skills/defining-the-niche-from-user-input/SKILL.md deleted file mode 100644 index b01d1ddd..00000000 --- a/.claude/skills/defining-the-niche-from-user-input/SKILL.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -name: defining-the-niche-from-user-input -description: >- - Defining the niche from user input. Use when the user needs a product workflow for business - analysis related to defining the niche from user input. Trigger terms: pm, - business-analysis, positioning, segmentation, niche. ---- - - - -# Defining the niche from user input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `defining-the-niche-from-user-input` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Defining the niche from user input venture brief with target segment, wedge, assumptions, and validation path - -Use this skill to run the Productize prompt contract for **Defining the niche from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Defining the niche from user input. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Analyze input for: audience demographics, interests/behaviors, geography/context, product/service attributes, and unique value points. -- Each niche must combine multiple dimensions (at least 3 of: demographics, interests, geography/context, use case, value driver). -- Avoid broad segments; each niche should be narrow enough to target with specific messaging. -- Do not invent unrelated industries, audiences, or value propositions not implied by `USER_INPUT`. -- Ensure all 10 niches are materially different from each other. - - -FORMAT -Return exactly this structure: - - - -[Brief synthesis of key input signals used to define niches] - -1. [Highly specific niche definition] -2. [Highly specific niche definition] -3. [Highly specific niche definition] -4. [Highly specific niche definition] -5. [Highly specific niche definition] -6. [Highly specific niche definition] -7. [Highly specific niche definition] -8. [Highly specific niche definition] -9. [Highly specific niche definition] -10. [Highly specific niche definition] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/demo-narratives-showing-user-goals/SKILL.md b/.claude/skills/demo-narratives-showing-user-goals/SKILL.md deleted file mode 100644 index d86e6d2e..00000000 --- a/.claude/skills/demo-narratives-showing-user-goals/SKILL.md +++ /dev/null @@ -1,615 +0,0 @@ ---- -name: demo-narratives-showing-user-goals -description: >- - Demo narratives showing user goals. Use when the user needs a product workflow for - stakeholder management related to demo narratives showing user goals. Trigger terms: - product-demo, storytelling, prototypes, user-goals, stakeholder-management. ---- - - - -# Demo narratives showing user goals - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `demo-narratives-showing-user-goals` -- **Lifecycle**: Align -- **Category**: Marketing -- **Primary artifact**: Demo narratives showing user goals stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Demo narratives showing user goals**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROTOTYPE}} -- {{USER_GOALS}} -- {{AUDIENCE}} -- {{CONSTRAINTS}} -- {{RESEARCH_INSIGHTS}} - - -GOAL -Produce a high-quality deliverable for: Demo narratives showing user goals. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are a prototype storytelling specialist skilled at crafting compelling demo narratives that showcase how products solve real user problems. Your task is to create story-driven prototype demonstrations that illustrate user jobs-to-be-done, making design decisions tangible and memorable for stakeholders. - -You will be provided with: - - -{{PROTOTYPE}} - - - -{{USER_GOALS}} - - - -{{AUDIENCE}} - - - -{{CONSTRAINTS}} - - - -{{RESEARCH_INSIGHTS}} - - -Follow these steps to create a compelling demo narrative: - -1. Define the protagonist and their context: - - Create a specific, believable user persona (not generic "Sarah the marketer") - - Establish their role, responsibilities, and daily workflow - - Identify their current pain points and frustrations - - Clarify what success looks like in their world - - Define their technical proficiency and tool familiarity - - Establish environmental context (where, when, with whom they work) - - Root persona in real research data, not assumptions - - Include relevant psychological motivators (what drives their decisions) - - Specify constraints they operate under (time, budget, authority) - - Identify who else is involved in their workflow (collaborators, approvers) - -2. Construct the narrative scenario: - - **Inciting incident**: What triggers the need to use your product? - - **Stakes**: Why does this matter? What happens if they fail? - - **Timeline**: How urgent is the need? What's the deadline? - - **Environmental factors**: What else is happening around them? - - **Emotional state**: How are they feeling at the start? - - **Prior attempts**: What have they already tried? - - **Success criteria**: What specific outcome would resolve their problem? - - **Realistic scope**: Keep scenario bounded and believable (not "redesign entire company") - - **Concrete details**: Specific numbers, names, dates that make it real - - **Relatable situation**: Audience should recognize this scenario - -3. Map the user journey through your prototype: - - **Entry point**: How do they arrive at your product? (link, search, bookmark, notification) - - **First impression**: What do they see/think in first 3 seconds? - - **Orientation**: How do they figure out what to do next? - - **Progressive disclosure**: What information appears when they need it? - - **Key decision points**: Where do they make choices? - - **Error/uncertainty moments**: Where might they hesitate or make mistakes? - - **Confirmation moments**: How does the system validate they're on track? - - **Aha moments**: When does value become clear? - - **Completion**: What signals they've achieved their goal? - - **Next steps**: What happens after this task? - - **Realistic pacing**: Allow time for reading, thinking, not just clicking - - **Natural interruptions**: Phone call, question from colleague (shows resilience) - - **Context switching**: They leave and come back (tests findability) - -4. Script the demo walkthrough with dialogue: - - **Scene setting**: "It's Tuesday afternoon, Alex has 30 minutes before a client meeting..." - - **Internal monologue**: Share user's thoughts at key moments - - **Narration style**: First-person ("I need to...") or third-person ("Alex notices...") - - **Action descriptions**: Specific interactions (click, scroll, type exact text) - - **System responses**: What happens after each action - - **Decision rationale**: Why user chooses option A over B - - **Emotional beats**: Frustration โ†’ confusion โ†’ clarity โ†’ confidence - - **Realistic hesitations**: "Hmm, where would that be... probably in settings" - - **Course corrections**: Show user recovering from wrong path - - **Time markers**: "2 minutes later..." to show efficiency - - **Verbatim UI text**: Quote exact button labels, headings, messages - - **Highlighting patterns**: "The bold CTA immediately draws attention to..." - -5. Add contextual annotations explaining design decisions: - - **Why this flow**: Design rationale for the path shown - - **Alternatives considered**: What other approaches were explored - - **Research backing**: User data supporting this design choice - - **Progressive disclosure**: Why certain info appears when it does - - **Accessibility considerations**: How inclusive design shows up - - **Error prevention**: How design prevents common mistakes - - **Cognitive load management**: How complexity is managed - - **Pattern consistency**: How this follows established conventions - - **Performance implications**: Loading states, perceived speed - - **Edge case handling**: What happens in unusual situations - - **Technical constraints**: Limitations that shaped decisions - - **Future enhancements**: What's intentionally deferred to V2 - -6. Prepare for live demonstration delivery: - - **Pre-demo setup**: What needs to be configured in advance - - **Data staging**: Realistic content loaded into prototype - - **Fallback plans**: What if tech fails mid-demo - - **Interaction notes**: Exactly which hotspots to click, what to type - - **Pacing guidelines**: How fast to move through each section - - **Pause points**: Where to stop for questions or emphasis - - **Audience engagement**: Where to ask "Have you experienced this?" - - **Comparison moments**: "Unlike current process where you'd..." - - **Zoom-in callouts**: Specific UI details to highlight - - **Branching paths**: Alternative routes if audience asks "what if..." - -7. Document variations for different audiences: - - **Executive version**: Business outcomes, ROI, strategic alignment (5 min) - - **End user version**: Detailed workflow, all features, realistic use (15 min) - - **Technical version**: Integration points, data flow, architecture (10 min) - - **Sales version**: Competitive advantages, objection handling (8 min) - - **Stakeholder review**: Design rationale, research validation (20 min) - - **Usability test**: Minimal guidance, observe natural exploration (no script) - -Present your demo narrative in this format: - - - -**Name:** [Specific name with relevant context - e.g., "Jordan Chen, Operations Manager at 200-person logistics company"] - -**Role and Responsibilities:** -[Detailed description of their job, what they're accountable for, who they report to] - -**Daily Workflow:** -[Typical day-in-the-life - what tools they use, what meetings they attend, what reports they create] - -**Current Pain Points:** -- [Pain 1]: [Specific frustration with concrete example] -- [Pain 2]: [Specific frustration with concrete example] -- [Pain 3]: [Specific frustration with concrete example] - -**Technical Proficiency:** -[Their comfort level with technology, what tools they already use successfully] - -**Success Metrics:** -[How their performance is measured - what they're trying to optimize] - -**Constraints:** -- Time: [Specific time pressures they face] -- Budget: [Financial limitations or approval processes] -- Authority: [What they can decide vs. need approval for] - -**Motivations:** -[What drives their behavior - career goals, team dynamics, personal values] - -**Research Foundation:** -[Which user interviews/studies informed this persona - quote specific findings] - - - -**Scene:** -[Vivid description of when/where this is happening - day, time, location, environmental context] - -**Inciting Incident:** -[What just happened that creates the need to use your product?] - -**Stakes:** -[Why this matters - what happens if they succeed vs. fail] - -**Timeline:** -[How urgent is this? When's the deadline?] - -**Emotional State:** -[How they're feeling - stressed, curious, overwhelmed, hopeful] - -**Prior Context:** -[What have they already tried? Why didn't it work?] - -**Success Outcome:** -[Concrete description of what resolution looks like] - -**Realistic Scope:** -[Boundaries of this scenario - what's in/out of scope] - -Example: -"It's Thursday at 3pm. Jordan just got out of a difficult client meeting where they promised updated logistics forecasts by tomorrow morning. The current spreadsheet process takes 4-5 hours of manual data wrangling, and Jordan has a team dinner at 6pm they can't miss. Their manager is copied on the client email, so there's visibility on this commitment. Jordan has tried automating parts of this before using Excel macros, but they break whenever column names change." - - - - -**Narration:** -[Scene-setting description in present tense] - -**Jordan's Thought:** -"[Internal monologue showing their mental state]" - -**Action:** -[Exactly what they do - specific clicks, URLs, navigation] - -**System Response:** -[What appears on screen - describe layout, key elements visible] - -**Jordan's Reaction:** -"[Thought about what they see]" - -**Design Note:** -[Annotation explaining why interface works this way - research backing, design principle, accessibility consideration] - -Example: -**Narration:** Jordan opens their laptop and clicks the bookmark for ForecastPro, which their team started piloting last week. - -**Jordan's Thought:** "Okay, I need to pull Q4 logistics data and create those regional forecasts they asked for. Let me see if this new tool can actually help." - -**Action:** Jordan lands on the dashboard homepage. - -**System Response:** The screen shows a clean interface with three prominent options: "Create New Forecast," "View Recent Reports," and "Import Data." A subtle notification badge shows "2" on Recent Reports. - -**Jordan's Reaction:** "Good, I can see my starting points clearly. That notification probably means the datasets I imported yesterday are ready." - -**Design Note:** We use a minimal three-option entry to prevent choice paralysis. Research showed users arriving with clear intent (create/view/import) - the IA reflects their mental model. The notification badge provides continuity for returning users without demanding attention. - - - -[Continue narrative through the main workflow - include 5-8 key moments:] -- Initial orientation and confidence building -- First meaningful action with immediate feedback -- Decision point with clear affordances -- Potential confusion or error โ†’ system guidance -- Progress indicator showing advancement -- Confirmation of successful completion -- Next action suggested - -[For each moment, include: Narration, Jordan's Thought, Action, System Response, Jordan's Reaction, Design Note] - - - -**Narration:** -[Description of reaching the goal] - -**Jordan's Thought:** -"[Realization of success and what it means]" - -**Action:** -[Final action - export, share, save, etc.] - -**System Response:** -[Confirmation message, next steps offered] - -**Jordan's Reaction:** -"[Emotional beat - relief, satisfaction, confidence]" - -**Time Check:** -[How long this took vs. old method] - -**Outcome:** -[What Jordan achieved and why it matters] - -Example: -**Narration:** The final forecast report generates in seconds, formatted exactly how the client expects it. - -**Jordan's Thought:** "Wait, that's it? That would've taken me until 7pm with the old process. And it's already in the right format." - -**Action:** Jordan clicks "Export to Email" and adds the client's address, with their manager CC'd. - -**System Response:** "Report sent successfully. Forecast will auto-update weekly and notify stakeholders." A subtle animation shows the email icon confirming delivery. - -**Jordan's Reaction:** "Okay, this actually worked. And now it'll update automatically? That's huge." - -**Time Check:** Task completed in 8 minutes vs. the usual 4-5 hours. - -**Outcome:** Jordan has the rest of the afternoon free, makes it to team dinner on time, and gained credibility with the client by delivering early. More importantly, this forecast will now maintain itself weekly. - - - - -**1. First Impression (0:30):** -[What makes user confident they're in right place] - -**2. Aha Moment (2:15):** -[When value becomes clear - what triggered the realization] - -**3. Trust Moment (4:30):** -[When user believes system is reliable - what convinced them] - -**4. Completion Moment (7:45):** -[When goal achieved - what confirmed success] - -**5. Delight Moment (8:00):** -[Unexpected positive - what exceeded expectations] - -[For each: timestamp, description, why it matters, supporting design element] - - - -**Design Decisions Showcased:** -1. [Decision]: [Rationale + Research backing] -2. [Decision]: [Rationale + Research backing] -3. [Decision]: [Rationale + Research backing] - -**Pattern Library Elements:** -- [Pattern used]: [Why appropriate for this context] -- [Pattern used]: [Why appropriate for this context] - -**Accessibility Features Highlighted:** -- [Feature]: [How it helps specific users] -- [Feature]: [How it helps specific users] - -**Progressive Disclosure Examples:** -- [Information]: [Why hidden until needed] -- [Information]: [Why hidden until needed] - -**Error Prevention:** -- [Mechanism]: [What mistake it prevents] -- [Mechanism]: [What mistake it prevents] - -**Performance Considerations:** -- [Optimization]: [Why it matters for this scenario] -- [Optimization]: [Why it matters for this scenario] - - - - -**Prototype Configuration:** -- [Setting to configure]: [Specific value] -- [Data to load]: [Where to source realistic content] -- [Browser/device]: [Recommended setup] - -**Rehearsal Checklist:** -- [ ] All hotspots clickable and lead to correct screens -- [ ] Realistic data loaded (names, numbers, dates) -- [ ] Timing rehearsed (should feel natural, not rushed) -- [ ] Annotations hidden unless presenter decides to show -- [ ] Fallback screenshots available if tech fails - - - -**Opening (30 seconds):** -"Let me show you how [persona] uses this to solve [specific problem]. Watch for how the design handles [key challenge]." - -**Scene Setting (15 seconds):** -"[Vivid description of scenario - day, time, what just happened]" - -**Walkthrough (5-10 minutes):** -[Step by step with exact interactions:] -1. [Action to take] โ†’ [What to say while doing it] โ†’ [What to point out] -2. [Action] โ†’ [Narration] โ†’ [Callout] -3. [Continue for key flow] - -**Pause Points:** -- After [moment]: "Notice how [design element] helps with [user need]" -- After [moment]: "Have you encountered this problem in your workflow?" -- After [moment]: "Unlike [current process], this approach [advantage]" - -**Closing (30 seconds):** -"In under [time], Jordan accomplished [outcome] - compared to [old way]. Key differentiators: [list 2-3 specific advantages shown]." - -**Q&A Preparation:** -- If asked about [edge case]: [Navigate to X screen and show Y] -- If asked about [integration]: [Show Z and explain technical approach] -- If asked about [alternative path]: [Click A instead of B to demonstrate] - - - -**Total Time:** [Recommended duration for full narrative] - -**Section Breakdown:** -- Setup and context: [X minutes] -- Core task demonstration: [Y minutes] -- Completion and outcome: [Z minutes] -- Q&A buffer: [W minutes] - -**Speed Guidelines:** -- Speak at conversational pace (not presentation pace) -- Allow 3-5 seconds after each screen transition for audience to orient -- Pause after key moments to let impact land -- Don't rush through error recovery - that's valuable to show - -**Energy Modulation:** -- Build excitement as user progresses toward goal -- Allow authentic hesitation moments (makes it believable) -- Emphasize relief/satisfaction at completion - - - -**If Technology Fails:** -- Option 1: [Screenshot walkthrough prepared] -- Option 2: [Video recording as backup] -- Option 3: [Whiteboard sketch of key screens] - -**If Audience Derails:** -- [Polite redirect]: "Great question - let me finish showing [X], then circle back to that" -- [Mark for later]: Add to parking lot list visible on screen - -**If Demo Breaks Mid-Flow:** -- [Recovery line]: "Let me skip ahead to the outcome..." [show completion state] -- [Acknowledge]: "That's actually helpful - shows why we need robust error handling" - - - - - -**Duration:** 5 minutes -**Focus:** Business outcomes, ROI, strategic fit -**Script Adjustments:** -- Start with the time/cost savings number -- Skip interaction details, show before/after states -- Emphasize competitive advantage and market differentiation -- End with adoption plan and success metrics - -**Key Moments to Show:** -1. Problem statement with financial impact -2. Solution in action (fast-forward through steps) -3. Outcome with measurable results - - - -**Duration:** 15 minutes -**Focus:** Complete workflow, all features, realistic use -**Script Adjustments:** -- Show every step with natural pacing -- Include error recovery and edge cases -- Demonstrate all key features, not just happy path -- Allow time for questions throughout - -**Key Moments to Show:** -[All moments from main script, plus:] -- Secondary features in context -- Settings and customization options -- Help resources and tooltips - - - -**Duration:** 10 minutes -**Focus:** Integration points, data architecture, technical capabilities -**Script Adjustments:** -- Open with architecture overview -- Show API endpoints or integration points during workflow -- Highlight data transformation and validation -- Demonstrate error handling and edge cases -- End with scalability and security considerations - -**Key Moments to Show:** -1. Data input and validation -2. System processing (what happens under hood) -3. Integration with other systems -4. Performance under load - - - -**Duration:** 8 minutes -**Focus:** Competitive advantages, objection handling, customer value -**Script Adjustments:** -- Start with customer's current pain -- Emphasize differentiation vs. alternatives -- Show ROI calculation in real-time -- Address common objections proactively -- End with implementation ease - -**Objection Handling Built In:** -- "Unlike [competitor], we handle [X] by..." -- "Customers worried about [Y] appreciate how we..." -- "This approach means you avoid [common pitfall]" - - - -**Duration:** 20 minutes -**Focus:** Design rationale, research validation, decisions made -**Script Adjustments:** -- Include all contextual annotations visible -- Reference specific user research findings -- Show alternative approaches considered -- Highlight open questions and areas for feedback -- Discuss iteration plans - -**Key Moments to Show:** -- Research insight โ†’ Design decision connection -- A/B test results informing choices -- Accessibility compliance -- Technical constraint handling - - - - -**If Audience Asks "What If User Wants to [Alternative Path]":** -[Describe the alternate route, which screens to show, how system adapts] - -**If Asked About Error States:** -[Which error to demonstrate, what recovery looks like] - -**If Asked About Mobile Experience:** -[How narrative changes on mobile device, what's different] - -**If Asked About First-Time vs. Returning User:** -[How onboarding differs, what changes after initial use] - - - -Remember: The best demo narratives feel like watching a real person solve a real problem. Avoid the temptation to show every feature - instead, show one complete journey that makes the value undeniable. Your audience should leave saying "I can see myself using this" rather than "That looks interesting." - - -FORMAT -Return exactly this structure: - - -Before finalizing your demo narrative, verify: -- [ ] Persona feels like a real person (not "User A" or generic archetype) -- [ ] Scenario is specific and believable (not abstract or overly broad) -- [ ] Stakes are clear (audience understands why this matters) -- [ ] Timeline creates appropriate urgency (not manufactured drama) -- [ ] Journey shows realistic pacing (allows time for thinking, not just clicking) -- [ ] Errors/uncertainty included (demonstrates resilience, not just happy path) -- [ ] Design decisions explained (audience learns the "why" behind the "what") -- [ ] Outcome is measurable (time saved, quality improved, frustration reduced) -- [ ] Emotional journey is authentic (frustration โ†’ clarity โ†’ confidence) -- [ ] Technical feasibility confirmed (everything shown actually works in prototype) - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/design-critique/SKILL.md b/.claude/skills/design-critique/SKILL.md deleted file mode 100644 index b35f87df..00000000 --- a/.claude/skills/design-critique/SKILL.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -name: design-critique -description: >- - Get structured design feedback on usability, hierarchy, and consistency. Use when asked to - review a design, critique a mockup, react to a screen, or provide feedback on a Figma link, - screenshot, or description from exploration through final polish. ---- - - - -# Design Critique - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `design-critique` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Design Critique UX/design review with findings, constraints, fixes, and acceptance checks - -Give structured design feedback across usability, hierarchy, consistency, accessibility, and polish. - -## Argument Hint - -`` - -## Usage - -```text -/design-critique $ARGUMENTS -``` - -## Inputs - -Accept: -- Figma URL. -- Screenshot. -- File reference. -- Live or local page URL. -- Detailed design description. - -If a Figma URL, browser URL, or file is available and the relevant tool is connected, inspect the artifact directly. Otherwise ask the user for the minimum design context needed. - -Ask for: -- What the design is. -- Who it is for. -- Stage: exploration, refinement, final polish, or handoff. -- Optional focus: mobile, onboarding, checkout, navigation, visual polish, accessibility, or another specific area. - -## Critique Framework - -### 1. First Impression - -Assess the first two seconds: -- What draws the eye first, and is that correct? -- What is the emotional reaction? -- Is the purpose immediately clear? - -### 2. Usability - -Check: -- Whether users can accomplish the intended goal. -- Navigation clarity. -- Obviousness of interactive elements. -- Step count and avoidable friction. -- Error, empty, loading, and edge states if visible. - -### 3. Visual Hierarchy - -Check: -- Reading order. -- Emphasis and priority. -- Typography scale and weight. -- Whitespace and grouping. -- CTA prominence. - -### 4. Consistency - -Check: -- Design system alignment. -- Spacing, color, radius, shadows, and typography consistency. -- Reuse of patterns for similar interactions. -- Naming and language consistency. - -### 5. Accessibility - -Do a practical pass: -- Contrast risk. -- Touch target size. -- Text readability. -- Form labels and instructions. -- Keyboard and screen reader risks if interaction can be assessed. - -For a full WCAG audit, recommend `accessibility-review`. - -## Feedback Rules - -- Be specific: name the element and the issue. -- Explain why the issue matters to the user or task. -- Suggest an alternative, not just a criticism. -- Include what works well. -- Match feedback to design stage: early exploration gets directional feedback; final polish gets precise issues. -- Avoid generic taste comments unless they connect to purpose, brand, or usability. - -## Output Format - -```markdown -## Design Critique: [Design Name] - -### Overall Impression - -[1-2 sentence first reaction: what works and the biggest opportunity] - -### Usability - -| Finding | Severity | Recommendation | -|---|---|---| -| [Issue] | Critical/Moderate/Minor | [Fix] | - -### Visual Hierarchy - -- **What draws the eye first**: [Element] - [whether this is correct] -- **Reading flow**: [How the eye moves through the layout] -- **Emphasis**: [Whether the right elements are emphasized] - -### Consistency - -| Element | Issue | Recommendation | -|---|---|---| -| [Typography/spacing/color/component] | [Inconsistency] | [Fix] | - -### Accessibility - -- **Color contrast**: [Pass/fail/risk for key text] -- **Touch targets**: [Adequate size?] -- **Text readability**: [Font size, line height, density] -- **Assistive tech risks**: [Keyboard or screen reader risks if visible] - -### What Works Well - -- [Positive observation 1] -- [Positive observation 2] - -### Priority Recommendations - -1. **[Most impactful change]** - [Why and how] -2. **[Second priority]** - [Why and how] -3. **[Third priority]** - [Why and how] -``` - -## Connected Tools - -If a design tool is connected: -- Pull the design directly and inspect components, tokens, typography, spacing, layers, and design-system consistency. - -If user feedback or research tools are connected: -- Cross-reference critique against recent user feedback, usability findings, or support tickets. - -If browser tooling is connected: -- Inspect live behavior, responsive layout, interaction states, focus order, and console errors. diff --git a/.claude/skills/design-handoff/SKILL.md b/.claude/skills/design-handoff/SKILL.md deleted file mode 100644 index 8ac3207e..00000000 --- a/.claude/skills/design-handoff/SKILL.md +++ /dev/null @@ -1,229 +0,0 @@ ---- -name: design-handoff -description: >- - Generate developer handoff specs from a design. Use when a design is ready for engineering - and needs a spec sheet covering layout, design tokens, component props, interaction states, - responsive breakpoints, edge cases, and animation details. ---- - - - -# Design Handoff - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `design-handoff` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Design Handoff UX/design review with findings, constraints, fixes, and acceptance checks - -Generate comprehensive developer handoff documentation from a design. - -## Argument Hint - -`` - -## Usage - -```text -/design-handoff $ARGUMENTS -``` - -## Inputs - -Accept: -- Figma URL. -- Screenshot. -- File reference. -- Live or local page URL. -- Detailed design description. - -If a Figma URL, browser URL, or file is available and the relevant tool is connected, inspect the artifact directly. Otherwise work from the provided description or ask only for missing details that materially affect implementation. - -Capture: -- What screen, feature, or component is being handed off. -- Target platform and tech stack, if known. -- Design system or token names, if known. -- Intended responsive breakpoints. -- Known edge cases or constraints. - -## What to Include - -### Visual Specifications - -Document: -- Exact measurements for padding, margins, widths, heights, gaps, and alignment. -- Design token references for colors, typography, spacing, radius, shadows, and motion. -- Raw values only when tokens are unavailable, ideally with a suggested token mapping. -- Responsive breakpoints and behavior. -- Component variants and visual states. - -### Interaction Specifications - -Document: -- Click, tap, submit, cancel, and navigation behavior. -- Hover, focus, active, selected, disabled, loading, success, warning, and error states. -- Transitions and animations, including duration and easing. -- Gesture support such as swipe, pinch, long press, or drag when relevant. - -### Content Specifications - -Document: -- Character limits. -- Truncation, wrapping, and overflow behavior. -- Empty states. -- Loading states. -- Error states. -- Required copy, helper text, labels, and validation messages. - -### Edge Cases - -Document: -- Minimum and maximum content. -- Long internationalized strings. -- Slow or failed network responses. -- Missing, partial, or stale data. -- Permission and unauthenticated states where relevant. - -### Accessibility - -Document: -- Focus order. -- ARIA labels and roles. -- Keyboard interactions. -- Screen reader announcements. -- Touch target size. -- Contrast risks or requirements. - -## Principles - -1. **Do not assume silently**: If a value, state, or behavior is not specified, label it as an assumption or open question. -2. **Use tokens first**: Reference `spacing-md` instead of `16px` when the token is known. -3. **Show all states**: Include default, hover, active, focused, disabled, loading, error, and empty states when applicable. -4. **Describe the reason**: Explain important responsive or interaction decisions so engineers can make consistent tradeoffs. - -## Output - -```markdown -## Handoff Spec: [Feature/Screen Name] - -### Overview -[What this screen or feature does, plus user context.] - -### Layout -[Grid system, breakpoints, responsive behavior, spacing, alignment, and sizing rules.] - -### Design Tokens Used -| Token | Value | Usage | -|-------|-------|-------| -| `color-primary` | #[hex] | CTA buttons, links | -| `spacing-md` | [X]px | Between sections | -| `font-heading-lg` | [size/weight/family] | Page title | - -### Components -| Component | Variant | Props | Notes | -|-----------|---------|-------|-------| -| [Component] | [Variant] | [Props] | [Special behavior] | - -### States and Interactions -| Element | State | Behavior | -|---------|-------|----------| -| [CTA Button] | Hover | [Background darkens or token changes] | -| [CTA Button] | Loading | [Spinner, disabled, preserves width] | -| [Form] | Error | [Border, message placement, focus behavior] | - -### Responsive Behavior -| Breakpoint | Changes | -|------------|---------| -| Desktop (>1024px) | [Default layout] | -| Tablet (768-1024px) | [What changes] | -| Mobile (<768px) | [What changes] | - -### Edge Cases -- **Empty state**: [What to show when no data exists] -- **Long text**: [Wrapping, truncation, tooltip, or expansion rules] -- **Loading**: [Skeleton, spinner, timeout, or progressive rendering behavior] -- **Error**: [Error state appearance and recovery action] - -### Animation / Motion -| Element | Trigger | Animation | Duration | Easing | -|---------|---------|-----------|----------|--------| -| [Element] | [Trigger] | [Description] | [ms] | [easing] | - -### Accessibility Notes -- [Focus order] -- [ARIA labels and roles needed] -- [Keyboard interactions] -- [Screen reader announcements] - -### Open Questions -- [Question] - [Owner or decision needed] -``` - -## Connected Tool Guidance - -If a design tool is connected: -- Pull exact measurements, tokens, component names, variants, and layer metadata from the design. -- Export or reference assets needed for implementation. -- Compare against the existing design system when possible. - -If a project tracker is connected: -- Link the handoff to the implementation ticket if the user asks. -- Draft sub-tasks for layout, components, states, accessibility, and QA. - -## Tips - -- Share the Figma link to enable exact measurements, tokens, and component info. -- Mention edge cases such as "what happens with 100 items" so the handoff covers boundary behavior. -- Specify the tech stack so implementation notes can match the codebase. diff --git a/.claude/skills/design-review/SKILL.md b/.claude/skills/design-review/SKILL.md deleted file mode 100644 index cf5f3206..00000000 --- a/.claude/skills/design-review/SKILL.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: design-review -description: >- - Design gate for UX quality, visual hierarchy, interaction states, accessibility, responsive - behavior, design-system fit, and handoff readiness. Use before build or after implementation - when product experience quality is at risk. ---- - - - -# Design Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `design-review` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Design review with experience readout, blocking issues, fixes, decision, and handoff - -Use this gate to decide whether the experience is coherent enough to build, ship, -or keep iterating. It is broader than a design critique because it owns the gate -decision and downstream handoff. - -## Artifact Format - -Use Markdown for short design findings. Use self-contained HTML when the review -needs side-by-side variants, responsive mockups, screenshots, accessibility notes, -state maps, or a visual fix board that design, eng, and QA can scan together. - -## Route Internally - -- `$design-critique` -- `$frontend-design` -- `$design-handoff` -- `$accessibility-review` -- `$ux-edge-cases-from-product-briefs` -- `$success-metrics-for-design-decisions` -- `$structured-json-descriptions-from-ui-screenshots` - -## Required Output - -Return: - -1. **Experience Readout**: hierarchy, flow, states, accessibility, responsiveness, and design-system fit. -2. **Blocking Issues**: problems that prevent build, QA, release, or learning. -3. **Fixes**: concrete design or implementation changes with acceptance checks. -4. **Decision**: approve, revise, split, or retest. -5. **Handoff**: what eng, QA, docs, or comms needs from the design gate. diff --git a/.claude/skills/design-system/SKILL.md b/.claude/skills/design-system/SKILL.md deleted file mode 100644 index 77c134ef..00000000 --- a/.claude/skills/design-system/SKILL.md +++ /dev/null @@ -1,296 +0,0 @@ ---- -name: design-system -description: >- - Audit, document, or extend a design system. Use when checking for naming inconsistencies or - hardcoded values across components, writing documentation for component variants, states, - and accessibility notes, or designing a new pattern that fits the existing system. ---- - - - -# Design System - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `design-system` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Design System UX/design review with findings, constraints, fixes, and acceptance checks - -Manage a design system by auditing for consistency, documenting components, or designing new patterns. - -## Argument Hint - -`[audit | document | extend] ` - -## Usage - -```text -/design-system audit -/design-system document [component] -/design-system extend [pattern] -``` - -## Modes - -### Audit - -Use when the user wants a full or targeted review of design system consistency. - -Check: -- Component naming consistency. -- Variant and state naming consistency. -- Token coverage for colors, typography, spacing, borders, shadows, and motion. -- Hardcoded values or arbitrary one-off styles. -- Missing states, variants, documentation, or accessibility notes. -- Components that overlap or solve the same problem inconsistently. - -### Document - -Use when the user wants documentation for an existing component. - -Document: -- Purpose and when to use it. -- Variants, sizes, states, and props. -- Content guidance. -- Accessibility requirements. -- Do and do-not usage guidance. -- Framework-appropriate code examples if the implementation stack is known. - -### Extend - -Use when the user wants a new component or pattern that fits the existing system. - -Define: -- The problem or system gap. -- Related existing components and why they are not enough. -- Proposed API, variants, states, and tokens. -- Accessibility behavior. -- Migration or adoption notes. -- Open questions that need design or engineering review. - -## Components of a Design System - -### Design Tokens - -Atomic values that define the visual language: -- Colors: brand, semantic, neutral, and data colors. -- Typography: scale, weights, families, and line heights. -- Spacing: scale, component padding, layout gaps. -- Borders: radius and width. -- Shadows: elevation levels. -- Motion: durations and easings. - -### Components - -Reusable UI elements with defined: -- Variants such as primary, secondary, and ghost. -- States such as default, hover, active, disabled, loading, and error. -- Sizes such as sm, md, and lg. -- Behavior, interactions, and animations. -- Accessibility roles, names, and keyboard behavior. - -### Patterns - -Common UI solutions combining components: -- Forms: input groups, validation, submission. -- Navigation: sidebar, tabs, breadcrumbs. -- Data display: tables, cards, lists. -- Feedback: toasts, modals, inline messages. - -## Principles - -1. **Consistency over novelty**: The system exists so teams do not reinvent common UI. -2. **Flexibility within constraints**: Components should be composable, not rigid. -3. **Document the usable contract**: If a variant, prop, state, or accessibility behavior is not documented, teams will guess. -4. **Version and migrate**: Breaking changes need migration paths, deprecated aliases, or adoption guidance. - -## Output: Audit - -```markdown -## Design System Audit - -### Summary -**Components reviewed:** [X] | **Issues found:** [X] | **Score:** [X/100] - -### Naming Consistency -| Issue | Components | Recommendation | -|-------|------------|----------------| -| [Inconsistent naming] | [List] | [Standard to adopt] | - -### Token Coverage -| Category | Defined | Hardcoded Values Found | -|----------|---------|------------------------| -| Colors | [X] | [X] instances of hardcoded hex | -| Spacing | [X] | [X] instances of arbitrary values | -| Typography | [X] | [X] instances of custom fonts/sizes | - -### Component Completeness -| Component | States | Variants | Docs | Score | -|-----------|--------|----------|------|-------| -| Button | Complete | Complete | Partial | 8/10 | -| Input | Complete | Partial | Missing | 5/10 | - -### Priority Actions -1. [Most impactful improvement] -2. [Second priority] -3. [Third priority] -``` - -## Output: Document - -```markdown -## Component: [Name] - -### Description -[What this component is and when to use it.] - -### Variants -| Variant | Use When | -|---------|----------| -| [Primary] | [Main actions] | -| [Secondary] | [Supporting actions] | - -### Props / Properties -| Property | Type | Default | Description | -|----------|------|---------|-------------| -| [prop] | [type] | [default] | [description] | - -### States -| State | Visual | Behavior | -|-------|--------|----------| -| Default | [description] | [behavior] | -| Hover | [description] | [interaction] | -| Active | [description] | [interaction] | -| Disabled | [description] | Non-interactive | -| Loading | [description] | [animation] | - -### Accessibility -- **Role**: [ARIA role] -- **Keyboard**: [Tab, Enter, Escape behavior] -- **Screen reader**: [Announced as...] - -### Do and Do Not -| Do | Do Not | -|----|--------| -| [Best practice] | [Anti-pattern] | - -### Code Example -[Framework-appropriate code snippet.] -``` - -## Output: Extend - -```markdown -## New Component: [Name] - -### Problem -[What user need or system gap this component addresses.] - -### Existing Patterns -| Related Component | Similarity | Why It Is Not Enough | -|-------------------|------------|----------------------| -| [Component] | [What is shared] | [What is missing] | - -### Proposed Design - -#### API / Props -| Property | Type | Default | Description | -|----------|------|---------|-------------| -| [prop] | [type] | [default] | [description] | - -#### Variants -| Variant | Use When | Visual | -|---------|----------|--------| -| [Variant] | [Scenario] | [Description] | - -#### States -| State | Behavior | Notes | -|-------|----------|-------| -| Default | [Description] | [Notes] | -| Hover | [Description] | [Interaction] | -| Disabled | [Description] | Non-interactive | -| Loading | [Description] | [Animation] | - -#### Tokens Used -- Colors: [Which tokens] -- Spacing: [Which tokens] -- Typography: [Which tokens] - -### Accessibility -- **Role**: [ARIA role] -- **Keyboard**: [Expected interactions] -- **Screen reader**: [Announced as...] - -### Open Questions -- [Decision that needs design review] -- [Edge case to resolve] -``` - -## Connected Tool Guidance - -If a design tool is connected: -- Audit components directly in the design file for naming, variants, token usage, and layer structure. -- Pull component properties and layer structure for documentation. -- Compare proposed extensions against existing libraries before inventing new patterns. - -If a knowledge base is connected: -- Search for existing component documentation and usage guidelines. -- Draft updates in the appropriate documentation format. - -## Tips - -- Start with an audit before deciding what to change. -- Document components while designing or updating them. -- Prioritize coverage over perfection: broad usable documentation is better than perfect docs for only a few components. diff --git a/.claude/skills/detailed-project-plans-from-project-briefs/SKILL.md b/.claude/skills/detailed-project-plans-from-project-briefs/SKILL.md deleted file mode 100644 index 2880940b..00000000 --- a/.claude/skills/detailed-project-plans-from-project-briefs/SKILL.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -name: detailed-project-plans-from-project-briefs -description: >- - Detailed project plans from project briefs. Use when the user needs a product workflow for - project management related to detailed project plans from project briefs. Trigger terms: - planning, scheduling, risk-management, execution. ---- - - - -# Detailed project plans from project briefs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `detailed-project-plans-from-project-briefs` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Detailed project plans from project briefs delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Detailed project plans from project briefs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_BRIEF}} - - -GOAL -Produce a high-quality deliverable for: "Detailed project plans from project briefs". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a detailed, realistic project plan from `{{PROJECT_BRIEF}}`, including: -- Project objectives, deliverables, constraints, and deadlines from the brief. -- Task/subtask breakdown with duration and resource estimates. -- Day-by-day plan, then weekly milestones, then monthly goals. -- Critical path analysis and schedule impact of delays. -- Risk assessment with likelihood, impact, and mitigation. -- Ambiguity review covering: what is unclear, why it matters, and how to resolve it. -- Final summary of timeline, milestones, critical path, and top risks. - -FORMAT -Return exactly this structure: - - - -[Include your project summary here] - - - -[Include your day-by-day breakdown here] - - - -[Include your week-by-week plan here] - - - -[Include your month-by-month plan here] - - - -[Include your critical path analysis here] - - - -[Include your risk assessment and mitigation strategies here] - - - - -[Include your analysis of ambiguous areas and proposed solutions here] - - -FAILURE -- Any required section (``, ``, ``, ``, ``, ``, ``) is missing or materially incomplete. -- Timeline logic is inconsistent across daily/weekly/monthly levels. -- Critical path, risks, or ambiguity handling is missing, shallow, or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/difficult-conversation-script-5-step-framework/SKILL.md b/.claude/skills/difficult-conversation-script-5-step-framework/SKILL.md deleted file mode 100644 index 6b00abb9..00000000 --- a/.claude/skills/difficult-conversation-script-5-step-framework/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: difficult-conversation-script-5-step-framework -description: >- - Difficult Conversation Script (5-Step Framework). Use when the user needs a product workflow - for stakeholder management related to difficult conversation script (5-step framework). - Trigger terms: coaching, communication, conflict-resolution, stakeholder-management. ---- - - - -# Difficult Conversation Script (5-Step Framework) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `difficult-conversation-script-5-step-framework` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Difficult Conversation Script (5-Step Framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Difficult Conversation Script (5-Step Framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Difficult Conversation Script (5-Step Framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Produce a concise, one-page difficult-conversation prep doc from provided context. -- Follow the sequence: Prepare -> Listen -> Empathize -> Clarify -> Solve. -- Include preparation notes: intent, non-negotiables, facts/examples, language traps, desired outcome, success criteria, medium, and setting. -- Provide 3-5 opening lines that are neutral, non-accusatory, impact-based, and perspective-inviting. -- Provide 5-7 open questions (what/how/when), including one perspective-taking question and one constraints question; avoid "why" framing. -- Include likely reactions with de-escalating responses, covering at least deny, deflect, emotional response, and counter-accuse. -- Include close/next steps with shared goals, options/trade-offs, commitments, owner/timeline, and follow-up check-in. -- Include a brief self-management checklist and escalation flags for HR/compliance. - -FORMAT -Return exactly this structure: - -1-Page Prep -[Concise prep bullets] - -Openers -[3-5 opening line options] - -Questions -[5-7 open questions] - -Reactions -> Responses -| Reaction | What I'll say (de-escalating) | -| --- | --- | -| [Reaction] | [Response] | - -Close & Next Steps -[Shared goals, options/trade-offs, commitments, owner/timeline, follow-up] - -Self-Management Checklist -- [Checklist item] - -Escalation Flags -- [HR/compliance flag or "None based on provided context"] - -FAILURE -- Any required section is missing or materially incomplete. -- Openers are accusatory/generic or not grounded in context. -- Questions violate constraints (too few/many, mostly "why", missing perspective-taking or constraints question). -- Reactions table omits core cases (deny, deflect, emotional, counter-accuse) or lacks de-escalation responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/disruptive-strategy-generation-from-what-if-questions/SKILL.md b/.claude/skills/disruptive-strategy-generation-from-what-if-questions/SKILL.md deleted file mode 100644 index 4572c0c0..00000000 --- a/.claude/skills/disruptive-strategy-generation-from-what-if-questions/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: disruptive-strategy-generation-from-what-if-questions -description: >- - Disruptive strategy generation from what-if questions. Use when the user needs a product - workflow for product strategy related to disruptive strategy generation from what-if - questions. Trigger terms: strategy, counter-positioning, brainstorming, disruption, - competitive-analysis. ---- - - - -# Disruptive strategy generation from what-if questions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `disruptive-strategy-generation-from-what-if-questions` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Disruptive strategy generation from what-if questions strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Disruptive strategy generation from what-if questions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY_OR_PRODUCT}} - - -GOAL -Produce a high-quality deliverable for: Disruptive strategy generation from what-if questions. -Success metric: -- Produces a grounded analysis of the incumbent and a diverse set of counter-positioning "what if" questions. -- Generates 20โ€“30 specific, actionable questions across multiple disruption dimensions. -- Keeps outputs tied to the company's business model and customer assumptions. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY_OR_PRODUCT}}`; if critical details are missing, state assumptions explicitly. -- Start with a brief, grounded analysis of how the incumbent makes money, core product elements, and strategic posture. -- Generate 20โ€“30 "what if" questions that are specific and actionable. -- Ensure diversity across at least these dimensions: - - technology, - - business model, - - customer experience, - - market expansion, - - sustainability, - - regulatory changes. -- Questions must challenge core assumptions and suggest plausible counter-positioning angles. - -FORMAT -Return exactly this structure: - - -[Analysis of the company/product and what makes it successful] - - - -1. [Your first "what if" question] -2. [Your second "what if" question] -... -[Continue until you have 20โ€“30 questions] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 20 or more than 30 questions are provided. -- Questions are generic, repetitive, or not tied to the company/product context. -- Diversity across the required dimensions is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/docs/SKILL.md b/.claude/skills/docs/SKILL.md deleted file mode 100644 index d30f47e7..00000000 --- a/.claude/skills/docs/SKILL.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -name: docs -description: >- - Documentation gate for README, guides, help content, API docs, release docs, migration - notes, support content, and docs consistency after product or code changes. Use when shipped - behavior and written guidance must match. ---- - - - -# Docs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `docs` -- **Lifecycle**: Launch & Learn -- **Category**: Delivery -- **Primary artifact**: Docs gate report with docs scope, consistency check, update plan, decision, and handoff - -Use this gate to keep documentation aligned with shipped behavior and user learning -needs. Docs owns accuracy, discoverability, and update scope. - -Docs is a post-change audit, not a writing prompt. It cross-references what changed -against what users, support, developers, and stakeholders will read. - -## Artifact Format - -Use Markdown for targeted doc edits or proposed sections. Use self-contained HTML -when the docs review needs a coverage map, stale-claim matrix, reader-journey map, -screenshots, API/example audit, or shareable documentation readiness report. -Treat implementation notes as source evidence when they explain why behavior -differs from the original spec. - -## Pre-Flight And Diff Analysis - -1. Identify the change source: diff, release candidate, product plan, shipped behavior, - API change, UX flow, support issue, or policy change. -2. Discover documentation surfaces: - - README / getting started - - docs site / guides - - API / SDK / CLI docs - - migration / upgrade notes - - changelog / release notes - - support / help center content - - internal runbooks / architecture docs - - privacy/security/legal docs when data practices changed -3. Classify the change: user behavior, developer behavior, API contract, data model, - setup, migration, pricing, permissions, support workflow, or operational process. -4. State which docs are in scope and which are intentionally excluded. - -## Per-File Audit - -For each relevant doc: - -| Doc | Audience | Current claim | Change impact | Action | -|---|---|---|---|---| - -Action must be one of: no change, update, add link, add section, remove stale claim, -flag for owner, or block release. - -## Update Rules - -- Be conservative: update only claims contradicted by the change or required for - successful use. -- Do not rewrite whole docs when a targeted section is enough. -- Do not remove large sections without an explicit decision. -- Preserve local voice and structure. -- Link docs together when discoverability is the issue. -- If developer docs are involved, call `$dx-review` for setup/examples/error paths. -- If customer-facing release language is involved, call `$comms-review` or - `$release-notes`. - -## Risky Documentation Decisions - -Ask or record a decision when: - -- the docs would promise a capability not fully shipped -- the product behavior is intentionally changing but migration guidance is unclear -- data, privacy, security, pricing, or contractual language changes -- multiple docs contradict each other and the source of truth is unclear -- release should block because users cannot succeed without docs - -## Consistency And Discoverability - -Check: - -- every changed concept is findable from README, docs nav, or an obvious entry point -- naming is consistent across product, docs, release notes, and UI -- examples still compile or match current API/CLI behavior when applicable -- screenshots or UI references still match current screens -- TODOs or known limitations are updated rather than left stale - -## Output Discipline - -If the host agent can edit files and the user asked for docs updates, apply targeted -updates and list changed files. If not editing, produce exact proposed sections and -owners. Never claim docs are current without a per-file audit or explicit caveat. - -## Route Internally - -- `$design-handoff` -- `$technical-translation-and-stakeholder-communication` -- `$skimmable-writing-transformation` -- `$release-notes` -- `$structured-requirements-from-design-assets` -- `$privacy-policy` when data practices change -- `$dx-review` when developer-facing docs are part of the user experience -- `$implementation-notes` when implementation-time decisions changed what docs must explain - -## Required Output - -Return: - -1. **Docs Scope**: docs affected, audiences, and behavior changes that must be reflected. -2. **Per-File Audit**: current claim, change impact, and action for each doc. -3. **Consistency Check**: contradictions, stale guidance, missing links, examples, screenshots, and unclear ownership. -4. **Updates Applied / Proposed**: exact files/sections or content blocks to add, revise, or leave unchanged. -5. **Risky Decisions**: promises, migration gaps, privacy/security/pricing language, or source-of-truth conflicts. -6. **Decision**: docs clear, update required, block release, or defer with owner. -7. **Handoff**: release, comms, DX, product, or support follow-up. diff --git a/.claude/skills/dogfood/SKILL.md b/.claude/skills/dogfood/SKILL.md deleted file mode 100644 index 87c70c6c..00000000 --- a/.claude/skills/dogfood/SKILL.md +++ /dev/null @@ -1,209 +0,0 @@ ---- -name: dogfood -description: >- - Browser-driven exploratory QA for web apps. Use when a local app, staging URL, or production - URL needs real-user dogfooding with sitemap coverage, flows, console checks, screenshots, - issue severity, blockers, and release evidence. ---- - - - -# Dogfood - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `dogfood` -- **Lifecycle**: Launch & Learn -- **Category**: Delivery -- **Primary artifact**: Dogfood QA report with pages tested, flows tested, console errors, screenshots, severity table, blockers, and release decision - -Dogfood is a routed QA skill for testing a web product like a real user. It is -not a fourth Productize playbook and not a replacement for the QA gate. QA calls -Dogfood when the target is a web UI and browser evidence is needed. - -Use this skill for local apps, staging URLs, production smoke checks, release -candidates with a web UI, and "test this URL end-to-end" requests. - -## Inputs - -Capture these before testing: - -- **Target**: URL, localhost route, deployed app, or app launch command. -- **Scope**: full site, changed flows, smoke test, regression pass, or named features. -- **Mode**: quick, standard, exhaustive, regression, or report-only. -- **Access**: credentials, seed data, feature flags, device/viewport requirements, and any unsafe actions to avoid. -- **Output directory**: default to `dogfood-output` when the host can save screenshots and a report. - -If authentication, a running server, seed data, or browser tooling is missing, -state the blocker and run the safest fallback coverage instead of inventing -results. - -## Tool Posture - -Use the host's browser tooling when available. Prefer tools that can: - -- navigate to URLs and local web apps -- inspect DOM or accessibility snapshots -- click, type, scroll, go back, and use keyboard navigation -- read browser console messages, JavaScript errors, and failed network requests -- capture screenshots or vision snapshots, with annotations when useful - -Check the console after every navigation and every significant interaction. -Silent JavaScript errors on core pages are reportable findings even when the UI -appears to work. - -## Workflow - -### Phase 1: Plan - -1. Create the output structure when file writes are appropriate: - - ```text - dogfood-output/ - screenshots/ - report.md - ``` - -2. Define the scope, test mode, assumptions, excluded surfaces, and known blockers. -3. Build a rough sitemap from visible navigation, route files, links, or app docs. -4. Identify primary user flows, including first-run, happy path, invalid input, - interrupted flow, empty state, and recovery paths. - -### Phase 2: Explore Pages - -For each page in scope: - -1. Navigate to the page. -2. Record URL, page purpose, visible state, and whether it loaded successfully. -3. Capture a screenshot or visual evidence. -4. Inspect DOM/accessibility text for missing labels, broken content, or hidden state. -5. Check browser console output and failed requests. -6. Scroll through the page and repeat visual/console checks when new content loads. - -### Phase 3: Exercise Flows - -Test the product like the intended user: - -- navigation between key routes -- signup, login, onboarding, dashboard, search, checkout, import/export, or other core flows -- valid and invalid form submissions -- empty submissions, duplicate submissions, rapid clicks, cancellation, and back navigation -- loading, error, empty, and permission states -- mobile or narrow viewport when the UI is responsive -- keyboard navigation, focus visibility, labels, and basic contrast/accessibility cues - -After each significant interaction, record expected behavior, actual behavior, -console output, and screenshot evidence when something changes or fails. - -### Phase 4: Classify Issues - -For every issue, capture: - -- severity: P0, P1, P2, or P3 -- category: functional, visual, accessibility, console, UX, content, performance, or data -- affected URL/page -- repro steps -- expected behavior -- actual behavior -- console errors or failed requests -- screenshot/evidence path -- likely owner/gate -- release impact and retest instruction - -Use `references/issue-taxonomy.md` for severity and category definitions. -De-duplicate issues before final reporting. - -### Phase 5: Report - -Use `templates/dogfood-report-template.md` unless the user asked for another -format. The report must be evidence-first and include: - -1. **Quality Scope**: target, mode, assumptions, and exclusions. -2. **Pages Tested**: URLs/pages visited and page-level results. -3. **Flows Tested**: user flows exercised, expected behavior, actual behavior, and result. -4. **Console Errors**: console messages, JavaScript errors, failed requests, or an explicit "none observed" with caveats. -5. **Screenshots/Evidence**: screenshots, traces, logs, DOM snapshots, command output, and paths. -6. **Severity Table**: counts by severity and category, sorted by release impact. -7. **Issues**: reproducible findings with owner, release impact, and retest steps. -8. **Blockers**: anything that prevented coverage or blocks release. -9. **Decision**: pass, conditional pass, retest, block, or escalate. -10. **Next Gate**: QA, release, docs, design, eng, operate, or product review. - -Do not report vague findings without repro steps and evidence. Do not claim a -surface was tested unless you navigated or inspected it in the current run. - -## Route Internally - -- `$qa` when the dogfood report needs broader acceptance, regression, or release-risk judgment. -- `$test-scenarios` when the team needs a reusable scenario matrix before dogfooding. -- `$acceptance-criteria-for-ui` when the UI expectations are ambiguous. -- `$accessibility-review` when accessibility defects need deeper review. -- `$systematic-debugging` when a confirmed issue needs root-cause analysis and a fix loop. -- `$release` when the dogfood result is release evidence. -- `$operate` when the result is a production smoke check or live-product health signal. - -## Required Output - -Return: - -1. **Quality Scope**: target, mode, assumptions, excluded surfaces, and blockers. -2. **Pages Tested**: each page/URL, evidence, console status, and result. -3. **Flows Tested**: each flow, expected behavior, actual behavior, evidence, and result. -4. **Console Errors**: errors/warnings/failed requests, or explicit none observed with caveats. -5. **Screenshots/Evidence**: screenshot paths, traces, logs, snapshots, and command outputs. -6. **Severity Table**: issue counts by severity and category. -7. **Issues**: severity, category, repro, expected, actual, evidence, owner, release impact, and retest step. -8. **Blockers**: missing access, missing data, unavailable tools, unsafe actions, or release blockers. -9. **Decision**: pass, conditional pass, retest, block, or escalate. -10. **Next Gate**: the next Productize gate or routed skill and why. diff --git a/.claude/skills/dogfood/references/issue-taxonomy.md b/.claude/skills/dogfood/references/issue-taxonomy.md deleted file mode 100644 index a2da3228..00000000 --- a/.claude/skills/dogfood/references/issue-taxonomy.md +++ /dev/null @@ -1,101 +0,0 @@ -# Dogfood Issue Taxonomy - -Use this taxonomy for browser-driven exploratory QA of web apps. - -## Severity - -### P0: Release Blocker - -The issue makes a core feature unusable, causes data loss, exposes sensitive -data, blocks authentication, prevents payment or critical completion, or creates -a blank/crashing app state. - -Examples: - -- blank page, crash loop, or fatal runtime error on a primary route -- form submission loses data or silently fails on a core flow -- users cannot log in, sign up, purchase, save, or complete the primary task -- security-sensitive data appears in page content, network output, or console logs - -### P1: High Impact - -The issue significantly impairs a key flow, but a workaround may exist. - -Examples: - -- primary button or navigation action does nothing -- valid input is rejected or valid results are missing -- critical content is absent, stale, or garbled -- uncaught JavaScript exception appears on a core page or after a core interaction -- key route links to a 404 or wrong destination - -### P2: Medium Impact - -The issue is noticeable and affects user experience, confidence, or reliability -without blocking the main flow. - -Examples: - -- layout misalignment, overlapping text, or responsive breakage -- images or media fail to load -- loading takes more than 3 seconds without feedback -- invalid input lacks useful validation feedback -- console warnings suggest deprecated, misconfigured, or unreliable behavior - -### P3: Low Impact - -The issue is polish-level and does not materially affect task completion. - -Examples: - -- typo, grammar issue, or inconsistent label -- minor spacing or alignment inconsistency -- placeholder text appears in a non-critical area -- favicon or secondary asset is missing -- non-sensitive debug logging remains in the console - -## Categories - -### Functional - -Features do not work as expected: broken buttons, bad navigation, failed forms, -incorrect data, or incomplete flows. - -### Visual - -Presentation defects: broken layouts, overlapping elements, missing media, -z-index issues, truncation, or responsive failures. - -### Accessibility - -Access barriers: missing labels, keyboard traps, weak focus indicators, poor -contrast cues, missing meaningful alt text, or screen-reader incompatible -structure. - -### Console - -Browser console and runtime problems: uncaught exceptions, unhandled promise -rejections, failed requests, CORS errors, mixed content warnings, deprecations, -or production debug output. - -### UX - -The feature works but the experience is unclear: confusing navigation, missing -loading state, no action feedback, inconsistent interaction patterns, missing -confirmation, or poor recovery guidance. - -### Content - -Text, media, or information problems: typos, placeholder content, outdated -information, missing sections, broken external links, or misleading labels. - -### Performance - -Slow or unstable behavior: long loading without feedback, jank, repeated -requests, hydration delays, or interactions that feel blocked. - -### Data - -Data correctness or integrity concerns: stale values, inconsistent state, -incorrect calculations, missing records, duplicate submissions, or mismatched -backend/frontend data. diff --git a/.claude/skills/dogfood/templates/dogfood-report-template.md b/.claude/skills/dogfood/templates/dogfood-report-template.md deleted file mode 100644 index 43507207..00000000 --- a/.claude/skills/dogfood/templates/dogfood-report-template.md +++ /dev/null @@ -1,101 +0,0 @@ -# Dogfood QA Report - -**Target:** {target_url} -**Date:** {date} -**Mode:** {mode} -**Scope:** {scope_description} -**Tester:** Productize Dogfood - -## Executive Summary - -{one_sentence_assessment} - -| Severity | Count | Release Impact | -|---|---:|---| -| P0 | {p0_count} | Blocks release | -| P1 | {p1_count} | Blocks or requires accepted risk | -| P2 | {p2_count} | Conditional pass or follow-up | -| P3 | {p3_count} | Polish backlog | -| Total | {total_count} | {overall_decision} | - -## Quality Scope - -- Target: {target_url} -- Scope: {scope_description} -- Assumptions: {assumptions} -- Exclusions: {excluded_surfaces} -- Blockers: {coverage_blockers} - -## Pages Tested - -| Page / URL | Purpose | Evidence | Console Status | Result | Notes | -|---|---|---|---|---|---| -| {page_or_url} | {purpose} | {screenshot_or_snapshot} | {console_status} | {result} | {notes} | - -## Flows Tested - -| Flow | Steps Exercised | Expected | Actual | Evidence | Result | -|---|---|---|---|---|---| -| {flow_name} | {steps} | {expected_behavior} | {actual_behavior} | {evidence_path} | {result} | - -## Console Errors - -| Page / Flow | Error or Warning | Severity | Evidence | Notes | -|---|---|---|---|---| -| {page_or_flow} | {console_output_or_none_observed} | {severity} | {evidence_path} | {notes} | - -## Screenshots / Evidence - -- {evidence_label}: {evidence_path} - -## Severity Table - -| # | Title | Severity | Category | URL / Flow | Release Impact | Owner | -|---|---|---|---|---|---|---| -| {n} | {title} | {severity} | {category} | {url_or_flow} | {release_impact} | {owner} | - -## Issues - -### Issue #{issue_number}: {issue_title} - -| Field | Value | -|---|---| -| Severity | {severity} | -| Category | {category} | -| URL / Flow | {url_or_flow} | -| Owner / Gate | {owner_or_gate} | -| Release Impact | {release_impact} | - -**Description:** {description} - -**Steps to Reproduce:** - -1. {step_1} -2. {step_2} -3. {step_3} - -**Expected Behavior:** {expected_behavior} - -**Actual Behavior:** {actual_behavior} - -**Evidence:** {screenshot_or_trace_path} - -**Console Output:** - -```text -{console_output} -``` - -**Retest Step:** {retest_instruction} - -## Blockers - -- {blocker_or_none} - -## Decision - -{pass_conditional_pass_retest_block_or_escalate} - -## Next Gate - -{next_productize_gate_and_reason} diff --git a/.claude/skills/draft-nda/SKILL.md b/.claude/skills/draft-nda/SKILL.md deleted file mode 100644 index 144d82a7..00000000 --- a/.claude/skills/draft-nda/SKILL.md +++ /dev/null @@ -1,245 +0,0 @@ ---- -name: draft-nda -description: >- - Draft NDA. Use when drafting a confidentiality or NDA document for partnership, customer, - vendor, hiring, or product collaboration discussions. ---- - - - -# Draft NDA - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `draft-nda` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: NDA draft for legal review with assumptions, clauses, and review flags - -Use when drafting a confidentiality or NDA document for partnership, customer, vendor, hiring, or product collaboration discussions. - -## Productize Contract - -- **Primary lifecycle**: Align -- **Supporting lifecycle**: none -- **Primary artifact**: NDA draft for legal review with assumptions, clauses, and review flags -- **Source method**: pm-skills-main/pm-toolkit/skills/draft-nda/SKILL.md - -## Legal Review Guardrail - -This skill creates a product/legal working draft for review. Do not present the output as legal advice or final compliance approval. Flag jurisdiction, data, party, and policy assumptions for qualified review. - -## Method - -You are an experienced legal document specialist with expertise in confidentiality agreements. Your role is to help draft detailed, clear, and professional Non-Disclosure Agreements between parties. - -## Purpose -Draft a comprehensive Non-Disclosure Agreement (NDA) between two parties. The NDA covers information types, jurisdiction, and clearly marks clauses that require legal review. Provide plain-language explanations to make the document accessible. - -## Important Disclaimer -**This is for informational purposes only and does not constitute legal advice. Always have a licensed attorney review the final document before execution. NDAs are legally binding contracts; professional legal review is essential.** - -## Input Arguments -- `$COMPANY_ONE_NAME`: Name of the first party/company -- `$COMPANY_ONE_ADDRESS`: Address of the first party/company -- `$COMPANY_ONE_REPS`: Names and titles of representatives (e.g., "John Smith, CEO; Jane Doe, General Counsel") -- `$COMPANY_TWO_NAME`: Name of the second party/company -- `$COMPANY_TWO_ADDRESS`: Address of the second party/company -- `$COMPANY_TWO_REPS`: Names and titles of representatives -- `$INFORMATION_TYPES`: Types of information to be shared (e.g., "business plans, customer lists, technical specifications, pricing data, source code") -- `$JURISDICTION`: Governing jurisdiction (e.g., "State of California, United States" or "England and Wales") - -## Process - -### Step 1: Clarify Requirements -Before drafting, note down: -- Are both parties companies or is one an individual? -- What specific types of information will be shared? -- Is this one-way (only one party shares) or mutual (both parties share)? -- What is the geographic jurisdiction? -- What is the intended duration of the NDA? - -### Step 2: Structure the NDA -Organize the NDA in standard sections: - -1. **Preamble** (Parties, definitions, effective date) -2. **Definitions** (What is "Confidential Information"?) -3. **Obligation to Maintain Confidentiality** (Core obligation) -4. **Permitted Disclosures** (Exceptions to confidentiality) -5. **Term and Duration** (How long does the NDA last?) -6. **Return or Destruction of Information** (What happens after?) -7. **Remedies** (Consequences for breach) -8. **General Provisions** (Governing law, jurisdiction, severability) - -### Step 3: Use Plain Language -Write each section in clear, accessible language. Avoid legal jargon where possible. Define terms the first time they're used. - -### Step 4: Highlight Clauses Needing Legal Review -Mark sections with [ LEGAL REVIEW REQUIRED] where customization or specific legal expertise is needed. Include explanations of what should be reviewed. - -### Step 5: Provide Context -Include brief notes explaining: -- Why each section is important -- What decisions need to be made by the parties -- Common pitfalls or considerations - -## NDA Template Structure - -Present the draft NDA in this order: - -**[COVER NOTE]** -A brief note explaining the NDA's purpose, the parties involved, and key provisions. - -**[FULL NDA DOCUMENT]** -The complete agreement ready for customization. - -**[NOTES ON KEY CLAUSES]** -Explanations of important sections and what may need legal customization. - ---- - -## Key Sections to Include - -### Preamble -- Introduce both parties clearly with full legal names and addresses -- State the purpose: exploring a potential business relationship, partnership, merger, etc. -- Define the "Effective Date" - -### Definitions -- **Confidential Information**: Specify what is considered confidential (business plans, financial data, technical specs, customer lists, etc.). Include scope. -- **Excluded Information**: Clarify what is NOT confidential (publicly available information, information independently developed, information received from third parties without confidentiality obligations) - -### Obligations -- Describe the receiving party's duty to keep information confidential -- Specify approved uses of the information -- Outline permitted disclosures (to employees, advisors, on a need-to-know basis) -- [ LEGAL REVIEW REQUIRED] Standard of care (e.g., "same care as own confidential information, but no less than reasonable care") - -### Permitted Disclosures -- Specify who can be told (employees, advisors, consultants on a need-to-know basis) -- Include a requirement that recipients also agree to confidentiality -- Add exception for legally required disclosures (with notice requirement, if possible) - -### Term and Duration -- Define the period during which information is being shared -- Define how long confidentiality obligations survive after the relationship ends -- [ LEGAL REVIEW REQUIRED] Consider different durations for different information types (trade secrets may require longer protection) - -### Return or Destruction -- Specify that the receiving party must return or securely destroy confidential information upon request or upon termination -- Option to certify in writing that destruction is complete -- Consider: does the receiving party keep one copy for legal compliance? - -### Remedies -- [ LEGAL REVIEW REQUIRED] State that breach may cause irreparable harm and that injunctive relief is available -- Clarify that remedies are in addition to other legal remedies available - -### General Provisions -- **Governing Law and Jurisdiction**: Specify which state or country's laws govern (e.g., California or England) -- [ LEGAL REVIEW REQUIRED] Dispute resolution process (litigation, arbitration, mediation) -- **Severability**: If one provision is invalid, others remain in force -- **Entire Agreement**: This NDA supersedes prior discussions -- **Amendments**: Specify that NDA can only be modified in writing, signed by both parties -- **Counterparts**: Parties can sign separate copies - ---- - -## Content Guidelines - -- **Plain Language**: Write for a primary-school-educated reader. Avoid Latin phrases, unnecessary legal terms. -- **Clarity over Precision**: Choose clear language first. Legal precision can be refined by attorneys. -- **Examples**: Where helpful, include examples of what is/isn't confidential information. -- **Specific Information Types**: Use the $INFORMATION_TYPES provided to make the agreement specific, not generic. -- **Mutual or One-Way**: If $INFORMATION_TYPES suggests only one party is sharing, note this as a one-way NDA. If both, use mutual language. - ---- - -## Output Format - -Present the NDA in three parts: - -### Part 1: Summary -Bullet-point overview of: -- Parties involved -- Information types covered -- Key duration and terms -- Jurisdiction - -### Part 2: Full NDA Document -A complete, ready-to-customize NDA document. - -### Part 3: Customization Notes -Guidance on: -- Sections marked for legal review -- Decisions parties need to make -- Common modifications based on situation -- Next steps (legal review, signing process) - ---- - -## Important Reminders - -- This is a starting point, not final legal advice -- Jurisdictions vary widely; have a lawyer in the relevant jurisdiction review -- Some industries (tech, pharma, finance) have specific NDA conventions -- Consider mutual vs. one-way requirements -- Think about duration: How long should the information be protected? -- Always have an attorney review before any party signs - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/dual-mode-ai-coding-assistant-staff-eng-intern/SKILL.md b/.claude/skills/dual-mode-ai-coding-assistant-staff-eng-intern/SKILL.md deleted file mode 100644 index eb0a1231..00000000 --- a/.claude/skills/dual-mode-ai-coding-assistant-staff-eng-intern/SKILL.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -name: dual-mode-ai-coding-assistant-staff-eng-intern -description: >- - Dual-mode AI coding assistant (Staff Eng + Intern). Use when the user needs a product - workflow for technical related to dual-mode ai coding assistant (staff eng + intern). - Trigger terms: software-development, coding-assistant, architecture, implementation, - workflow, ai. ---- - - - -# Dual-mode AI coding assistant (Staff Eng + Intern) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `dual-mode-ai-coding-assistant-staff-eng-intern` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Dual-mode AI coding assistant (Staff Eng + Intern) AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Dual-mode AI coding assistant (Staff Eng + Intern)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Dual-mode AI coding assistant (Staff Eng + Intern). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Operate in one of two modes only: -- `Staff Engineer Mode` for planning/architecture/roadmaps. -- `Intern Mode` for scoped implementation and validation. -- Select mode by request intent: -- Use `Staff Engineer Mode` for design/plan/approach or multi-component strategy. -- Use `Intern Mode` for concrete file/function implementation requests. -- If unclear, ask one brief mode-clarification question before proceeding. -- In `Staff Engineer Mode`: -- Provide architecture guidance, risks, dependencies, and a phased implementation checklist. -- Include file-level scope, test checkpoints, and edge-case considerations. -- Do not provide detailed code implementation. -- In `Intern Mode`: -- Work strictly within defined scope and specified files/functions. -- Make atomic, targeted implementation changes matching existing style. -- Include requested validation output and concrete failure notes/fixes when needed. -- Do not expand scope or add unsolicited architectural redesign. - -FORMAT -Return exactly this structure: - -If mode is unclear: -Mode Clarification Question: -Would you like planning support (Staff Engineer mode) or scoped implementation (Intern mode)? - -If Staff Engineer Mode: -Mode: Staff Engineer -Context Check: -- [known context] -- [critical missing info, if any] -Architecture & Strategy: -- [recommendation] -Implementation Plan (phased checklist): -1. [step] - Files: [path/function scope] - Dependencies: [items] - Test checkpoint: [verification] - Risks/edge cases: [notes] -Complexity Notes: -- [step -> estimated complexity] - -If Intern Mode: -Mode: Intern -Scope: -- Files/functions in scope: [items] -- Out of scope: [items] -Implementation: -- [atomic change 1] -- [atomic change 2] -Validation: -- Requested output: [result summary] -- Failures/warnings: [items or "None"] -- Specific fixes (if needed): [items] - -FAILURE -- Mode boundaries are violated (planning mixed with implementation or vice versa). -- Mode is unclear but no clarification question is asked. -- Staff Engineer output lacks phased checklist, file-level scope, or test checkpoints. -- Intern output expands scope beyond requested files/functions or includes unsolicited architecture changes. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/dx-review/SKILL.md b/.claude/skills/dx-review/SKILL.md deleted file mode 100644 index 780a9603..00000000 --- a/.claude/skills/dx-review/SKILL.md +++ /dev/null @@ -1,243 +0,0 @@ ---- -name: dx-review -description: >- - Developer experience gate for APIs, CLIs, SDKs, docs, examples, onboarding, error messages, - setup paths, integration friction, and time-to-hello-world. Use when developers are a - primary user or adoption path. ---- - - - -# DX Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `dx-review` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: DX review with developer persona, integration path, friction findings, decision, and handoff - -Use this gate when the product surface is developer-facing. DX owns whether a -developer can understand, integrate, debug, and trust the product quickly. - -DX Review is the developer-facing product gate. It combines plan review and live -audit: if a target is available, test the actual path; if not, score the plan and -name what evidence is missing. - -## Artifact Format - -Use Markdown for a short DX finding list. Use self-contained HTML when the review -needs a time-to-hello-world path map, setup funnel, API/CLI examples, error-message -audit, scorecard, or shareable developer onboarding report. Include copyable -commands and examples when that makes the artifact more useful. - -## Applicability Gate - -Run DX Review when the product includes an API, CLI, SDK, library, integration, -developer docs, automation platform, workflow builder, plugin, webhooks, or anything -where developers must understand and integrate the product. - -If developers are not a primary user or adoption path, route to `$design-review`, -`$docs`, `$eng-review`, or `$product-review` instead. - -## Step 0: Target Discovery - -Find or ask for: - -- product type: API, CLI, SDK, library, platform, docs, integration, or workflow tool -- target developer persona -- install/setup path -- hello-world path -- docs URL or repo docs -- examples/samples -- auth/key setup -- error surfaces -- support/community path -- plan baseline if a prior DX review exists - -## DX Principles - -Review against: - -- zero friction at T0 -- time to hello world -- learn by doing -- copy-paste examples that work -- guessable names and contracts -- errors that explain problem, cause, fix, and link -- progressive disclosure -- credible migration/upgrade path -- support path when stuck -- measurement of developer success - -## TTHW Benchmarks - -Use Time To Hello World as the anchor metric: - -- **Excellent**: under 5 minutes with no sales call and no unnecessary setup. -- **Good**: 5-15 minutes with clear docs and one obvious path. -- **Risky**: 15-30 minutes or multiple ambiguous setup paths. -- **Broken**: over 30 minutes, missing docs/examples, or blocked by auth/setup. - -State whether TTHW is measured, inferred, or unknown. - -## Review Passes - -### Pass 1: Getting Started - -- Can a new developer identify the first step? -- Is setup linear and recoverable? -- Are prerequisites explicit? -- Does the first successful result arrive fast? - -### Pass 2: API / CLI / SDK Design - -- Are names, arguments, responses, and errors predictable? -- Are defaults safe? -- Are examples realistic? -- Is versioning or compatibility visible? - -### Pass 3: Error Messages And Debugging - -For each key error surface: - -| Error | Problem | Cause | Fix | Link/next step | -|---|---|---|---|---| - -Errors that only say "failed" or expose internals without a fix are blockers. - -### Pass 4: Documentation And Learning - -- Is there a clear conceptual model? -- Are quickstart, guides, reference, and examples separated appropriately? -- Can developers search and navigate without guessing vocabulary? -- Are screenshots, snippets, and commands current? - -### Pass 5: Upgrade And Migration - -- How do developers move from old to new behavior? -- Are breaking changes named? -- Is there a rollback or compatibility story? -- Are deprecations timed and discoverable? - -### Pass 6: Developer Environment And Tooling - -- Local dev path -- sandbox/playground -- logs/traces -- CLI help/autocomplete -- editor integration -- CI examples -- test stubs or fixtures - -### Pass 7: Community And Support - -- Where does a stuck developer go? -- Are issues, examples, FAQ, and contact paths obvious? -- Is the escalation path appropriate for the product stage? - -### Pass 8: Measurement - -- What developer activation event matters? -- Is TTHW measured? -- Are docs searches, failed auth/setup, API errors, and support contacts instrumented? -- What feedback loop improves DX after release? - -## Scorecard - -Score each pass 0-10 and include evidence: - -| Dimension | Score | Evidence | Top fix | -|---|---:|---|---| - -Overall score: - -- 8-10: strong enough to ship/grow -- 6-7: usable with clear follow-ups -- 4-5: risky; likely adoption friction -- 0-3: blocks developer adoption - -## Boomerang Check - -If a plan claimed a DX target, compare plan vs reality: - -- promised TTHW vs measured/inferred TTHW -- promised docs/examples vs actual -- promised errors/debugging vs actual -- promised migration/support vs actual - -Do not let a plan score substitute for live evidence when a live path exists. - -## Route Internally - -- `$technical-architecture-brief-from-product-requirements-doc` -- `$backend-design` -- `$spec-writing` -- `$verification` -- `$docs` -- `$skimmable-writing-transformation` -- `$technical-translation-and-stakeholder-communication` - -## Required Output - -Return: - -1. **Developer Persona**: who is integrating, their goal, and their time-to-value constraint. -2. **DX Path**: install/setup, hello world, docs, examples, errors, debugging, and support path. -3. **TTHW**: measured, inferred, or unknown; include benchmark and blocker. -4. **Scorecard**: eight pass scores with evidence and top fix. -5. **Friction Findings**: blockers, confusing names, missing examples, bad errors, trust gaps, and migration/support risks. -6. **Boomerang Comparison**: plan vs reality when a prior DX promise exists. -7. **Decision**: approve, revise, block, or test with developers. -8. **Handoff**: docs, eng, product, release, QA, or comms follow-up. diff --git a/.claude/skills/easy-signal-identification-from-product-assumption/SKILL.md b/.claude/skills/easy-signal-identification-from-product-assumption/SKILL.md deleted file mode 100644 index d84dbdbb..00000000 --- a/.claude/skills/easy-signal-identification-from-product-assumption/SKILL.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -name: easy-signal-identification-from-product-assumption -description: >- - Easy signal identification from product assumption. Use when the user needs a product - workflow for user research related to easy signal identification from product assumption. - Trigger terms: user-research, assumptions, validation. ---- - - - -# Easy signal identification from product assumption - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `easy-signal-identification-from-product-assumption` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Easy signal identification from product assumption research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Easy signal identification from product assumption**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{ASSUMPTION}} - - -GOAL -Produce a high-quality deliverable for: Easy signal identification from product assumption. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Design an early, efficient validation signal for `{{ASSUMPTION}}` (`We believe that ...`). -- Output must be plain text only: no XML/HTML tags, no code fences. -- Use optional context if provided (segment, function, stage, constraints, asset access, time/budget); if missing, infer minimally and note in summary. -- Internally classify assumption lens (Desirability / Feasibility / Viability / Usability) and choose methods accordingly. -- Apply suitability rules: -- Enterprise/B2B with procurement/security: favor interviews, LOIs, security dry-runs, demos, ROI/TCO checks, RFP/API alignment; avoid fake-door/consumer funnel tactics. -- SMB SaaS: favor discovery calls, lightweight trial/offer tests, POC requests, list tests, analytics. -- Consumer: favor ad intent, waitlist conversion, community/panel, preorders, competitor-behavior proxies. -- Regulated contexts: favor standards mapping, SME/regulatory preflight, de-identified/synthetic data; avoid sensitive-data collection without approvals. -- Feasibility assumptions: favor spikes, benchmarks, vendor/data audits over user-facing tests where unnecessary. -- Quality bar for selected signal: -- Early (idea/prototype viable), cheap, attributable, decisive (quantified threshold), context-suitable, and ethical/compliant. -- Provide exactly three sections in this order: `SCRATCHPAD`, `EFFICIENT SIGNAL`, `SUMMARY`. - -FORMAT -Return exactly this structure: - -SCRATCHPAD -- [Signal name] โ€” [positive evidence] โ€” [quick capture method] โ€” [context suitability] -- [At least 5 total lines] - -EFFICIENT SIGNAL -Signal description: [clear signal] -Method: [minimal-step approach] -Suitability: [why this fits context] -Earliest stage: [Idea | Prototype | Alpha | Beta] -Participants/sample: [who/how many] -Timebox & cost: [duration and estimate] -Success threshold: [quantified pass/fail criterion] -Data captured: [metrics/notes/artifacts] -Risks/ethics: [risks and mitigations] -Next evidence rung: [single next step if positive] - -SUMMARY -[3-5 sentences restating the assumption, diagnostic lens, rationale for chosen signal, and key excluded options] - -FAILURE -- Output is not plain text or includes XML/HTML/code fences. -- Missing required sections or wrong section order (`SCRATCHPAD`, `EFFICIENT SIGNAL`, `SUMMARY`). -- `SCRATCHPAD` has fewer than 5 distinct signals. -- `EFFICIENT SIGNAL` misses any required line or lacks quantified success threshold. -- Selected method violates suitability/ethics constraints for the given context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/effective-customer-interview-guides-for-any-topic/SKILL.md b/.claude/skills/effective-customer-interview-guides-for-any-topic/SKILL.md deleted file mode 100644 index 449edf95..00000000 --- a/.claude/skills/effective-customer-interview-guides-for-any-topic/SKILL.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -name: effective-customer-interview-guides-for-any-topic -description: >- - Effective customer interview guides for any topic. Use when the user needs a product - workflow for user research related to effective customer interview guides for any topic. - Trigger terms: user-research, interviews, discussion-guide. ---- - - - -# Effective customer interview guides for any topic - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `effective-customer-interview-guides-for-any-topic` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Effective customer interview guides for any topic research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Effective customer interview guides for any topic**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: Effective customer interview guides for any topic. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Create a comprehensive customer interview discussion guide for `{{TOPIC}}` to support feature-development insights. -- Internally analyze topic components, interview priorities, and interview flow before writing the final guide. -- Build sections in this order: -- Introduction and warm-up. -- Current situation and workflow. -- Challenges and pain points. -- Desired outcomes and goals. -- Exploration of potential solutions. -- Wrap-up and next steps. -- Use best practices from Mom Test and Continuous Discovery Habits: -- Open-ended, non-leading, behavior-based questions. -- Focus on past experiences over hypotheticals. -- Prioritize highest-value questions first in each section. -- Use friendly professional tone, numbered questions, and optional interviewer prompts in `[brackets]`. -- Output only the final ``; do not include analysis/thinking notes. - -FORMAT -Return exactly this structure: - - -[Brief introduction for the interviewer, explaining the purpose of the interview and key points to remember] - -1. Introduction and Warm-up - 1.1. [Question] - 1.2. [Question] - [Additional questions as needed] - -2. Current Situation and Workflow - 2.1. [Question] - 2.2. [Question] - [Additional questions as needed] - -3. Challenges and Pain Points - 3.1. [Question] - 3.2. [Question] - [Additional questions as needed] - -4. Desired Outcomes and Goals - 4.1. [Question] - 4.2. [Question] - [Additional questions as needed] - -5. Exploration of Potential Solutions - 5.1. [Question] - 5.2. [Question] - [Additional questions as needed] - -6. Wrap-up and Next Steps - 6.1. [Question] - 6.2. [Question] - [Additional questions as needed] - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Required sections are missing or question numbering/order is inconsistent. -- Questions are leading, hypothetical-first, or not behavior-based. -- Questions are not prioritized by importance within each section. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `interview script`, `mom test`, `warm-up`, `jtbd probing`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.claude/skills/effective-customer-interview-guides-for-any-topic/references/pm-skills-main-merge.md b/.claude/skills/effective-customer-interview-guides-for-any-topic/references/pm-skills-main-merge.md deleted file mode 100644 index a08bd2e5..00000000 --- a/.claude/skills/effective-customer-interview-guides-for-any-topic/references/pm-skills-main-merge.md +++ /dev/null @@ -1,113 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to strengthen interview scripts with warm-up, core exploration, wrap-up, Mom Test behavior, and non-leading JTBD probes. - -## Routing Signals - -- interview script -- mom test -- warm-up -- jtbd probing - -## pm-product-discovery/skills/interview-script/SKILL.md - -## Customer Interview Script - -Create a structured interview script that surfaces real insights, not just opinions. Follows "The Mom Test" principles -- ask about their life, not your idea. - -### Domain Context - -Customer interviews are one source in **Stage 1 (Explore)** of continuous discovery. Other sources: stakeholder interviews, usage analytics, data analytics, surveys, market trends, SEO/SEM analysis. The PM needs direct access to users, stakeholders, engineers, and designers -- "without proxies." The **Product Trio** (PM + Designer + Engineer -- Teresa Torres) should work together on discovery, not just the PM alone. - -### Context - -You are preparing a customer interview script for research on **$ARGUMENTS**. - -If the user provides files (personas, hypothesis lists, product briefs, or previous interview notes), read them first. - -### Instructions - -1. **Clarify research objectives**: - - What specific questions does the team need answered? - - What decisions will this research inform? - - What assumptions need validation? - -2. **Create the interview script** with these sections: - - ### Opening (2-3 min) - - Introduce yourself and the purpose (learning, not selling) - - Set expectations: "There are no right or wrong answers. We're here to learn from your experience." - - Ask permission to record (if applicable) - - Confirm time available - - ### Warm-Up: Context & Background (5 min) - - "Tell me about your role and what a typical day/week looks like." - - "How long have you been doing [activity related to the product area]?" - - Goal: Build rapport and understand their context - - ### Core Exploration: Jobs to Be Done (15-20 min) - - **Current situation and behavior** (past tense, specific instances): - - "Walk me through the last time you [did the thing we're exploring]. What happened?" - - "What tools or methods did you use?" - - "How long did it take? Who else was involved?" - - **Pain points and frustrations** (observe, don't lead): - - "What was the hardest part about that?" - - "If you could wave a magic wand, what would change?" - - "What have you tried to solve this? What happened?" - - **Desired outcomes** (their words, not yours): - - "What does 'good' look like for you in this area?" - - "How would you know if this was working well?" - - **Willingness to pay / priority** (skin in the game): - - "How much time/money do you currently spend on this?" - - "Have you looked for a better solution? What did you find?" - - "What would you give up to have this solved?" - - ### Probing Techniques - Use these when you hit an interesting thread: - - **"Tell me more about that"** -- opens up any topic - - **"Why?"** (asked gently, 2-3 times) -- gets to root causes - - **"Can you give me a specific example?"** -- moves from opinions to facts - - **"What happened next?"** -- follows the story - - **"How did that make you feel?"** -- captures emotional intensity - - ### The Mom Test Rules - - Ask about **their life**, not your idea - - Ask about **the past**, not the future ("Would you use X?" is useless) - - **Talk less, listen more** -- aim for 80/20 split - - **Never pitch** during the interview - - Look for **strong emotions** -- they signal real pain or delight - - **Compliments are noise** -- "That sounds cool!" tells you nothing - - ### Wrap-Up (3-5 min) - - "Is there anything I didn't ask that you think is important?" - - "Who else should I talk to about this?" - - Thank them for their time - - Share next steps (if any) - -3. **Customize the script**: Adapt questions to the specific product area, persona, and research objectives. Add or remove sections based on the interview length available. - -4. **Include a note-taking template**: - ``` - Participant: [Name / ID] - Date: [Date] - Key Jobs: [What they're trying to accomplish] - Current Solution: [What they use today] - Biggest Pain: [Their #1 frustration] - Desired Outcome: [What success looks like] - Willingness to Pay: [How much they invest / would invest] - Surprise Finding: [Something unexpected] - Follow-up: [Next steps] - ``` - -Save as markdown. Include both the script and the note-taking template. - ---- - -### Further Reading - -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) diff --git a/.claude/skills/empathy-maps/SKILL.md b/.claude/skills/empathy-maps/SKILL.md deleted file mode 100644 index 09fdfc0f..00000000 --- a/.claude/skills/empathy-maps/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: empathy-maps -description: >- - Empathy maps. Use when the user needs a product workflow for user research related to - empathy maps. Trigger terms: user-research, empathy-map, personas. ---- - - - -# Empathy maps - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `empathy-maps` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Empathy maps research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Empathy maps**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{AUDIENCE}} -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: Empathy maps. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a detailed empathy map for `{{AUDIENCE}}` in relation to `{{TOPIC}}`. -- Include all eight categories: -- Thinks -- Feels -- Says -- Does -- Sees -- Hears -- Pains -- Goals -- For each category, provide 3-5 numbered insights that are specific, non-redundant, and behaviorally meaningful. -- Prioritize depth over surface-level statements, including motivations, fears, desires, social influences, and decision drivers where relevant. -- End with a concise summary of key takeaways and implications. - -FORMAT -Return exactly this structure: - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -1. [Insight] -2. [Insight] -3. [Insight] - - - -[Brief key-takeaways and implications] - - - -FAILURE -- `` wrapper or any required category/summary tag is missing or malformed. -- Any category has fewer than 3 insights. -- Insights are generic, repetitive across categories, or not tied to `{{AUDIENCE}}` and `{{TOPIC}}`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/eng-review/SKILL.md b/.claude/skills/eng-review/SKILL.md deleted file mode 100644 index 8dc2d9c0..00000000 --- a/.claude/skills/eng-review/SKILL.md +++ /dev/null @@ -1,223 +0,0 @@ ---- -name: eng-review -description: >- - Engineering gate for architecture, data flow, system boundaries, implementation risk, test - strategy, performance, security, observability, and build readiness. Use before or after - implementation when technical execution can block shipping. ---- - - - -# Eng Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `eng-review` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Engineering review with architecture readout, execution risks, test strategy, decision, and handoff - -Use this gate to decide whether the technical plan or implementation is coherent, -testable, maintainable, and safe enough for the next playbook move. - -Eng Review is the execution gate. It should read like a strong engineering manager -reviewing whether a plan can actually ship, be tested, be operated, and be changed -later without surprising the team. - -## Artifact Format - -Use Markdown for concise technical findings. Use self-contained HTML when the -review needs architecture diagrams, data-flow maps, risk heatmaps, annotated code -snippets, sequence diagrams, or a shareable PR/implementation explainer. If -implementation ambiguities must be preserved while coding, call -`$implementation-notes` and keep the requested notes file current. - -## Pre-Review Audit - -Before reviewing: - -1. Read the product plan, relevant code, architecture docs, tests, TODOs, and - prior gate outputs. -2. Detect the platform, runtime, data stores, external services, test framework, - and deployment path when a repo exists. -3. Mark stale diagrams, stale plans, stale tests, or review outputs that predate - the current code or product scope. -4. Identify whether the review is plan-mode, diff-mode, post-fix, or release-gate - support. -5. If the plan touches 8+ files or creates 2+ new classes/services/modules, run a - scope-reduction challenge before deep review. - -## Scope Challenge - -Ask: - -- What is the smallest implementation that proves the product outcome? -- What existing code, component, data model, or service can be reused? -- What can be a follow-up PR or later loop? -- What architecture decision becomes expensive to reverse? -- What would make a competent engineer unable to ship a useful slice in two weeks? - -## Review Passes - -### 1. Architecture And Data Flow - -Trace the actual path through the system: - -- entry point -- authentication/authorization -- input validation -- state changes -- persistence -- async/background work -- external calls -- output/rendering -- error handling -- observability - -Include an ASCII diagram for non-trivial flows: - -```text -User/Input -> Boundary -> Service/Model -> Data Store -> Output - | | - errors logs/metrics -``` - -Flag hidden coupling, cyclic dependencies, unclear ownership, migration risk, and -state transitions that are not explicit. - -### 2. Code Quality And Maintainability - -- Is the abstraction necessary or premature? -- Are names, boundaries, and contracts guessable? -- Does the plan follow existing repo patterns? -- Are edge cases handled where they occur, not patched downstream? -- Is there any metadata churn or unrelated refactor risk? - -### 3. Test Strategy - -Detect existing test infrastructure first. Then require: - -- unit tests for pure logic and edge conditions -- integration tests for contracts/data flow -- regression tests for changed behavior that could break existing users -- eval tests for AI/prompt/model behavior -- e2e tests only for critical paths or high-risk flows - -If the review identifies a regression, add a regression test requirement. Do not -treat regression coverage as optional. - -### 4. Failure Modes And Rescue Paths - -List realistic production failures: - -| Flow | Failure mode | User impact | Detection | Recovery | -|---|---|---|---|---| - -Cover timeouts, nil/empty values, permissions, stale state, duplicate submission, -partial writes, race conditions, retries, idempotency, and rollback. - -### 5. Security, Privacy, And Data Integrity - -- Does the change expose sensitive data? -- Are permissions checked at the right boundary? -- Are inputs trusted too early? -- Are audit logs or consent requirements needed? -- Does rollback leave data in a coherent state? - -### 6. Performance And Operability - -- What is the expected load or data size? -- What query, render, or model-call path could get slow? -- What metric, trace, log, or alert would reveal trouble? -- Can support/debugging reconstruct what happened three weeks later? - -### 7. Parallelization And Sequencing - -When implementation is non-trivial, propose slices with disjoint write scopes and -dependencies. Do not parallelize work that shares fragile files or unresolved -interfaces. - -## Decision Protocol - -For each engineering issue: - -- State the risk and evidence. -- Recommend revise, split, spike, test, instrument, or block. -- If a decision affects architecture, scope, or test burden, handle it separately. -- If the fix is obvious and local, state the fix and continue. -- Never approve with hidden unresolved engineering decisions. - -## Route Internally - -- `$technical-architecture-brief-from-product-requirements-doc` -- `$backend-design` -- `$spec-writing` -- `$engineering-problem-solving-and-solution-structuring` -- `$tdd` -- `$systematic-debugging` -- `$verification` -- `$implementation-notes` - -## Required Output - -Return: - -1. **Architecture Readout**: boundaries, data flow, dependencies, state, and failure modes. -2. **Execution Risks**: complexity, coupling, migration risk, security, performance, and observability gaps. -3. **Diagrams**: architecture/data-flow/state diagrams when the flow is non-trivial. -4. **Test Strategy**: unit, integration, regression, e2e, eval, and verification coverage needed. -5. **Failure Mode Register**: failure, impact, detection, and recovery. -6. **Decision**: approve, revise, split, spike, or block. -7. **Handoff**: QA, release, docs, DX, or product gate needs. -8. **Completion Summary**: status, confidence, stale artifacts, unresolved decisions, and accepted technical risks. diff --git a/.claude/skills/engineering-problem-solving-and-solution-structuring/SKILL.md b/.claude/skills/engineering-problem-solving-and-solution-structuring/SKILL.md deleted file mode 100644 index fa6cb514..00000000 --- a/.claude/skills/engineering-problem-solving-and-solution-structuring/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: engineering-problem-solving-and-solution-structuring -description: >- - Engineering Problem Solving and Solution Structuring. Use when the user needs a product - workflow for technical related to engineering problem solving and solution structuring. - Trigger terms: engineering, problem-solving, solution-design, tradeoff-analysis, technical. ---- - - - -# Engineering Problem Solving and Solution Structuring - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `engineering-problem-solving-and-solution-structuring` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Engineering Problem Solving and Solution Structuring AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Engineering Problem Solving and Solution Structuring**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_TO_SOLVE}} - - -GOAL -Produce a high-quality deliverable for: Engineering Problem Solving and Solution Structuring. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{PROBLEM_TO_SOLVE}}` and produce a structured engineering solution assessment. -- Provide: -- Problem overview. -- Key challenges. -- Three distinct solution options. -- Pros/cons analysis for each solution. -- One additional/hybrid solution. -- Final recommendation with rationale. -- Each required section must contain at least four detailed, thoughtful sentences. -- Keep recommendations technically grounded, explicit about trade-offs, and practical for implementation. - -FORMAT -Return exactly this structure: - -[Overview of the problem] -[Key challenges in solving the problem] -[First potential solution] -[Second potential solution] -[Third potential solution] -[Analysis of pros and cons of Solution 1] -[Analysis of pros and cons of Solution 2] -[Analysis of pros and cons of Solution 3] -[Additional or hybrid solution] -[Final recommendation on the best approach] - -FAILURE -- Any required section is missing, malformed, or materially incomplete. -- Any required section has fewer than four sentences. -- Solutions are redundant, non-distinct, or lack trade-off analysis. -- Recommendation does not clearly justify why one approach is preferred. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/event-tracking-schemas-from-ui-and-metrics-requirements/SKILL.md b/.claude/skills/event-tracking-schemas-from-ui-and-metrics-requirements/SKILL.md deleted file mode 100644 index fda5451a..00000000 --- a/.claude/skills/event-tracking-schemas-from-ui-and-metrics-requirements/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: event-tracking-schemas-from-ui-and-metrics-requirements -description: >- - Event tracking schemas from UI and metrics requirements. Use when the user needs a product - workflow for business analysis related to event tracking schemas from ui and metrics - requirements. Trigger terms: pm, business-analysis, analytics, event-tracking, metrics. ---- - - - -# Event tracking schemas from UI and metrics requirements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `event-tracking-schemas-from-ui-and-metrics-requirements` -- **Lifecycle**: Design -- **Category**: Analytics -- **Primary artifact**: Event tracking schemas from UI and metrics requirements UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Event tracking schemas from UI and metrics requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{UI_DESCRIPTION}} -- {{METRICS_AND_BEHAVIORS}} - - -GOAL -Produce a high-quality deliverable for: Event tracking schemas from UI and metrics requirements. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Identify key interactive UI elements and user actions implied by `UI_DESCRIPTION`. -- Map each proposed event to one or more items in `METRICS_AND_BEHAVIORS`. -- For each event, include only high-value properties needed for analysis and decision-making. -- Avoid duplicate or redundant events that measure the same action at the same granularity. -- Use descriptive, implementation-ready event names and property descriptions. - - -FORMAT -Return exactly this structure: - - - -[Event Name] -[When the event should be triggered] - -- property1: [description] -- property2: [description] -- ... - -[Brief explanation of why this event and its properties are important for the given metrics/behaviors] - -[Repeat for each proposed event] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/exec-feedback-without-context-to-actionable-design-requirements/SKILL.md b/.claude/skills/exec-feedback-without-context-to-actionable-design-requirements/SKILL.md deleted file mode 100644 index 2323c88d..00000000 --- a/.claude/skills/exec-feedback-without-context-to-actionable-design-requirements/SKILL.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: exec-feedback-without-context-to-actionable-design-requirements -description: >- - Exec feedback without context to actionable design requirements. Use when the user needs a - product workflow for stakeholder management related to exec feedback without context to - actionable design requirements. Trigger terms: ux-design, executive-communication, - requirements, feedback-interpretation, stakeholder-management. ---- - - - -# Exec feedback without context to actionable design requirements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `exec-feedback-without-context-to-actionable-design-requirements` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Exec feedback without context to actionable design requirements UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Exec feedback without context to actionable design requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{EXEC_FEEDBACK}} -- {{CURRENT_DESIGN_CONTEXT}} -- {{PROJECT_BACKGROUND}} - - -GOAL -Produce a high-quality deliverable for: Exec feedback without context to actionable design requirements. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Decode `{{EXEC_FEEDBACK}}` into actionable design intent using `{{CURRENT_DESIGN_CONTEXT}}` and `{{PROJECT_BACKGROUND}}`. -- Distinguish concern, desired outcome, feedback type, and whether it is a requirement vs preference. -- Identify missing context required to execute. -- Produce 2-3 concrete interpretations with "done" criteria, implications, effort, and likelihood. -- Provide clarifying questions covering intent, priority, success, and data. -- Propose interim next steps and a respectful communication plan aligned to executive intent. - -FORMAT -Return exactly this structure: - - - - -[What problem or opportunity is the executive highlighting?] - - - -[What result is the executive hoping to achieve?] - - - -[Classify as: Strategic direction, Quality concern, Risk mitigation, User impact, Personal preference, or Unclear] - - - -[Assess whether this is: -- Must-have requirement (blocks launch without it) -- Important improvement (should address if feasible) -- Nice-to-have suggestion (consider if time permits) -- Personal preference (may or may not be valid concern)] - - - - -[List specific context needed to action the feedback: -- What defines success for addressing this? -- What are the constraints? -- How urgent/important is this? -- Who has final decision authority? -- When does this need to be resolved? -- What data would inform the decision?] - - - - -**What This Could Mean:** -[Specific interpretation of the feedback] - -**If This Is The Intent, "Done" Looks Like:** -[Concrete, testable criteria for addressing the feedback] - -**Design Implications:** -[Specific design changes that would address this interpretation] - -**Effort Required:** -[Time/complexity to implement] - -**Likelihood:** -[High/Medium/Low based on context] - - - -**What This Could Mean:** -[Alternative specific interpretation] - -**If This Is The Intent, "Done" Looks Like:** -[Concrete, testable criteria] - -**Design Implications:** -[Specific design changes] - -**Effort Required:** -[Time/complexity] - -**Likelihood:** -[High/Medium/Low] - - - -**What This Could Mean:** -[Third possible interpretation, if applicable] - -**If This Is The Intent, "Done" Looks Like:** -[Concrete, testable criteria] - -**Design Implications:** -[Specific design changes] - -**Effort Required:** -[Time/complexity] - -**Likelihood:** -[High/Medium/Low] - - - - - -[Questions to uncover what the executive really wants: -- Example: "When you mentioned X, were you concerned about Y or Z?"] - - - -[Questions to establish importance: -- Example: "Is this a must-have for launch, or something we should address post-launch?"] - - - -[Questions to define acceptance criteria: -- Example: "What would you need to see to feel confident this concern is addressed?"] - - - -[Questions to gather validation data: -- Example: "Would you like to see user research on this, or is this based on strategic direction?"] - - - - -[Propose actions that make progress while awaiting clarification: -- Research options for addressing concern -- Create low-fidelity explorations of different interpretations -- Gather data that would inform the decision -- Identify quick wins that address concern partially -- Document implications of different approaches] - - - -**Recommended Approach for Follow-up:** -[Describe how to engage the executive to get needed clarity: -- When to reach out (immediately vs. wait for next check-in) -- How to frame the conversation (focus on outcomes, show options) -- What to prepare (mockups, data, tradeoff analysis) -- Who else should be involved] - -**Draft Message:** -[Provide a template message requesting clarification that: -- Acknowledges the feedback -- Shows you've thought about it -- Presents interpretations -- Requests specific input -- Proposes next steps] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Interpretations are generic, non-testable, or not grounded in provided context. -- Clarifying questions fail to cover intent, priority, success, and data. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/executive-and-update-review/SKILL.md b/.claude/skills/executive-and-update-review/SKILL.md deleted file mode 100644 index e0268120..00000000 --- a/.claude/skills/executive-and-update-review/SKILL.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -name: executive-and-update-review -description: >- - Executive & Update Review. Use when the user needs a product workflow for stakeholder - management related to executive & update review. Trigger terms: executive-communication, - leadership, storytelling, presentations, stakeholder-management. ---- - - - -# Executive & Update Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `executive-and-update-review` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Executive & Update Review stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Executive & Update Review**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Executive & Update Review. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Review a draft executive update/deck and optimize for clarity, brevity, and decision impact. -- Rewrite `TL;DR` as exactly 3 bullets: what is wanted, why now, what changes. -- Diagnose issues with explicit `Issue -> Fix` callouts (including vague/defensive/buried lead/over-detail/missing risk or ask). -- Propose a clean narrative: Hook, Stakes, Options (with trade-offs), Recommendation, Ask (decision/resources/timeline). -- Rewrite the core section in plain language (`<=200` words). -- Provide 3-minute speaking notes with timing: opening (`15s`), body (`2m30s`), close (`15s`), including one story/data point, one risk, and one clear ask. -- Recommend slide/page economy and a one-slide executive summary layout. -- Replace hedging/passive voice with direct, credible phrasing aligned to business goals and next actions. - -FORMAT -Return exactly this structure: - -TL;DR (3 bullets) -- [What I want] -- [Why now] -- [What changes] - -Issue -> Fix -| Issue | Fix | -| --- | --- | -| [Issue] | [Fix] | - -Narrative Structure -Hook: [text] -Stakes: [text] -Options (with trade-offs): [text] -Recommendation: [text] -Ask (decision/resources/timeline): [text] - -Core Rewrite -[<=200 words plain-language rewrite] - -3-Minute Speaking Notes -Opening (15s): [text] -Body (2m30s): [text including one story/data point and one risk] -Close (15s): [text with one clear ask] - -Slide Economy & One-Slide Layout -Cuts/Merges: [what to remove or combine] -One-Slide Executive Summary Layout: [sections and ordering] - -FAILURE -- Any required section is missing or materially incomplete. -- `TL;DR` is not exactly 3 bullets or does not map to the required three intents. -- Core rewrite exceeds 200 words or remains vague/defensive/passive. -- Speaking notes miss required timing structure, risk, story/data point, or clear ask. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/executive-decks-from-quick-dirty-test-analysis/SKILL.md b/.claude/skills/executive-decks-from-quick-dirty-test-analysis/SKILL.md deleted file mode 100644 index b2bbe0d1..00000000 --- a/.claude/skills/executive-decks-from-quick-dirty-test-analysis/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: executive-decks-from-quick-dirty-test-analysis -description: >- - Executive decks from Quick Dirty Test analysis. Use when the user needs a product workflow - for presentation & communication related to executive decks from quick dirty test analysis. - Trigger terms: executive-communication, decision-support, hypothesis-testing, risk-analysis, - quick-dirty-test. ---- - - - -# Executive decks from Quick Dirty Test analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `executive-decks-from-quick-dirty-test-analysis` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Executive decks from Quick Dirty Test analysis UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Executive decks from Quick Dirty Test analysis**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SLIDE_DECK_CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Executive decks from Quick Dirty Test analysis. -Success metric: -- Identifies critical assumptions and failure modes that executives would scrutinize. -- Provides risk-dimensioning analyses and decision-driving questions. -- Includes an executive-ready summary with practical deck-improvement recommendations. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{SLIDE_DECK_CONTEXT}}`; if information is missing, state assumptions explicitly. -- Apply Quick Dirty Test logic: - - What must be true for the hypothesis/investment to succeed? - - How could the investment fail or "blow up"? -- Prioritize items that materially affect executive go/no-go decisions. -- Keep outputs concise, evidence-oriented, and directly usable for deck revisions. - -FORMAT -Return exactly this structure: - - - -[List the key assumptions here, one per line] - - - -[List the potential risks or ways the investment could fail, one per line] - - - -[List the analyses needed to support or reject the investment, one per line] - - - -[List the key questions to dimension the risks, one per line] - - - - -[Brief findings summary and recommendations to strengthen the executive deck] - - -FAILURE -- `` or `` is missing, malformed, or incomplete. -- Any required subsection in `` is missing. -- Analysis is not executive-decision oriented (missing investment belief/failure logic). -- Recommendations are generic and not actionable for deck improvement. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/explore-data/SKILL.md b/.claude/skills/explore-data/SKILL.md deleted file mode 100644 index 4d40f80e..00000000 --- a/.claude/skills/explore-data/SKILL.md +++ /dev/null @@ -1,277 +0,0 @@ ---- -name: explore-data -description: >- - Profile and explore a dataset to understand its shape, quality, and patterns. Use when - encountering a new table or file, checking null rates and distributions, spotting duplicates - or suspicious values, or deciding which dimensions and metrics to analyze. ---- - - - -# Explore Data - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `explore-data` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Explore Data analytics diagnosis with metric readout, caveats, decision, and next instrumented step - -Generate a comprehensive data profile for a table or file before deeper analysis. - -## Argument Hint - -`` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/.claude/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md b/.claude/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md deleted file mode 100644 index c0198290..00000000 --- a/.claude/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: feature-impact-models-from-kpis-and-assumptions -description: >- - Feature impact models from KPIs and assumptions. Use when the user needs a product workflow - for business analysis related to feature impact models from kpis and assumptions. Trigger - terms: pm, business-analysis, financial-modeling, kpi-impact. ---- - - - -# Feature impact models from KPIs and assumptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-impact-models-from-kpis-and-assumptions` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Feature impact models from KPIs and assumptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_INFO}} -- {{KPIS_TO_ESTIMATE}} - - -GOAL -Produce a high-quality deliverable for: Feature impact models from KPIs and assumptions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Build a procedural task list that covers: - - key assumptions, - - baseline metric calculations, - - per-KPI impact estimation, - - sensitivity analysis. -- Execute the tasks and show calculations step by step using explicit formulas/equations. -- For each KPI, provide: - - point estimate, - - assumptions and calculations used, - - brief explanation of feature-to-KPI impact mechanism. -- If information is missing, state what is missing, add a reasonable assumption, label it clearly, and proceed. -- Prioritize transparent math and reasoning over spreadsheet-like verbosity. -- Keep conclusions focused on executive decision-making (investment impact, major drivers, key risks). - - -FORMAT -Return exactly this structure: - - - -[List the procedural tasks used to build the model] - - - -[Step-by-step calculations, formulas, assumptions, and point estimates for each KPI] - - - -[Feature overview, KPI estimate table/list, key assumptions, sensitivity-analysis takeaways, and executive conclusions] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md b/.claude/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md deleted file mode 100644 index 73a774b8..00000000 --- a/.claude/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- - - - -# Feature results analysis from draft to final report - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-results-analysis-from-draft-to-final-report` -- **Lifecycle**: Launch & Learn -- **Category**: Analytics -- **Primary artifact**: Feature results readout with iterate, rollback, kill, or scale recommendation - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/features-reframing-and-projects-shape-up/SKILL.md b/.claude/skills/features-reframing-and-projects-shape-up/SKILL.md deleted file mode 100644 index b8dffefb..00000000 --- a/.claude/skills/features-reframing-and-projects-shape-up/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: features-reframing-and-projects-shape-up -description: >- - Features reframing and projects Shape Up. Use when the user needs a product workflow for - technical related to features reframing and projects shape up. Trigger terms: - product-strategy, shaping, scope-management, stakeholder-management, technical. ---- - - - -# Features reframing and projects Shape Up - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `features-reframing-and-projects-shape-up` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Features reframing and projects Shape Up**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_OR_PROJECT}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Features reframing and projects Shape Up. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reframe `{{FEATURE_OR_PROJECT}}` using Shape Up principles and provided `{{CONTEXT}}`. -- Provide a shaped work definition that is concrete enough for delivery but avoids build-phase implementation detail. -- Include: -- Appetite assessment (`1-2 weeks` or `6 weeks`) with rationale. -- Problem framing (problem-first, not solution-first). -- Boundary definition (in-scope / out-of-scope). -- Solution sketch at fat-marker level. -- Risks/rabbit holes and circuit-breakers. -- Explicit no-gos. -- Executive constraint language to secure scope commitment and prevent mid-cycle scope creep. -- Keep output focused on shaping quality, delivery constraints, and stakeholder alignment. - -FORMAT -Return exactly this structure: - -Shape Up Reframe - -Appetite Assessment -- Recommended appetite: [1-2 weeks or 6 weeks] -- Why this appetite: [rationale] - -Problem Framing -- Core problem: [problem statement] -- Why this matters now: [impact/context] -- Success condition: [what success looks like] - -Boundary Definition -- In scope: - - [item] -- Out of scope: - - [item] - -Solution Sketching (Fat Marker Level) -- Key approach: [high-level approach] -- Main interaction/surface 1: [conceptual behavior] -- Main interaction/surface 2: [conceptual behavior] - -Risks and Rabbit Holes -- [risk/rabbit hole] -- Circuit-breaker: [constraint or stop-rule] - -No-gos -- [explicit exclusion] - -Executive Constraints -- Commitment language: [specific wording to secure scope agreement] -- Change-control rule: [how new requests are handled mid-cycle] -- Escalation path: [who decides if scope must change] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Output drifts into build-phase implementation details instead of shaping-level decisions. -- Boundaries/no-gos are vague or do not constrain scope. -- Executive constraint handling is missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/finance-modeling-kernel/SKILL.md b/.claude/skills/finance-modeling-kernel/SKILL.md deleted file mode 100644 index c4c664f5..00000000 --- a/.claude/skills/finance-modeling-kernel/SKILL.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: finance-modeling-kernel -description: >- - Shared Productize Finance calculation and validation kernel for exact formulas, input - normalization, assumption checks, units, warnings, and acceptance-tested finance math used - by valuation, DCF, cost-of-capital, capital-structure, VC deal, and market-context skills. ---- - - - -# Finance Modeling Kernel - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `finance-modeling-kernel` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings - -## Purpose - -Shared calculation and validation library used by all Productize Finance skills. -Use this skill when a finance workflow needs exact formulas, normalized inputs, -assumption checks, error handling, units, or validation before making a recommendation. - -## Kernel Modules - -- `finance-modeling-kernel/time_value.py`: PV, FV, annuities, perpetuities, spot-rate streams. -- `finance-modeling-kernel/dcf.py`: NPV, IRR, payback, free cash flow, terminal value, ROIC, growth. -- `finance-modeling-kernel/returns.py`: realized returns, expected return, variance, volatility, covariance, correlation. -- `finance-modeling-kernel/risk.py`: portfolio variance, covariance, correlation, beta, regression beta. -- `finance-modeling-kernel/capm.py`: CAPM, unlevered beta, relevered beta. -- `finance-modeling-kernel/wacc.py`: WACC with market-value weights. -- `finance-modeling-kernel/apv.py`: tax shields and APV. -- `finance-modeling-kernel/valuation.py`: DCF valuation, terminal value, EV-to-equity bridge, multiples, sensitivities. -- `finance-modeling-kernel/capital_structure.py`: EV, equity value, leverage, MM, tax shields, APV. -- `finance-modeling-kernel/bond_math.py`: bond price, yield to maturity, current yield, credit spread. -- `finance-modeling-kernel/vc_method.py`: burn, runway, VC target multiple, pre/post-money, shares. -- `finance-modeling-kernel/cap_table.py`: fully diluted shares, ownership, dilution, cap table sum checks. -- `finance-modeling-kernel/convertible_notes.py`: note conversion amount, discount price, cap price, shares. -- `finance-modeling-kernel/safes.py`: SAFE conversion price, SAFE shares, post-money SAFE ownership. -- `finance-modeling-kernel/preferred_stock.py`: liquidation preference and preferred payoff waterfalls. -- `finance-modeling-kernel/option_pools.py`: investor-friendly and founder-friendly option pool math. -- `finance-modeling-kernel/market_context.py`: market cap, weights, listing changes, CAGR. -- `finance-modeling-kernel/validation.py`: shared validation errors and warning helpers. -- `finance-modeling-kernel/tests/`: acceptance tests for the minimum formula examples. - -## Finance Output Format - -All Productize Finance agents must return: - -1. **Inputs** -2. **Assumptions** -3. **Formula used** -4. **Calculation** -5. **Result** -6. **Interpretation** -7. **Warnings** - -## Global Guardrails - -1. Never compare cash flows at different dates without compounding or discounting. -2. Use market values, not book values, for valuation and WACC weights whenever possible. -3. Match discount rates to cash-flow risk. -4. Do not use a company WACC for a project with materially different risk. -5. Do not mix financing cash flows into operating free cash flow. -6. Use NPV as the primary investment decision rule. -7. Treat IRR, payback, and multiples as supporting tools, not final truth. -8. For VC deals, always state whether share counts are basic or fully diluted. -9. For option pools, always state whether the pool is investor-friendly or founder-friendly. -10. For convertible notes and SAFEs, always read the conversion definition before calculating. -11. For preferred stock, model the payoff waterfall, not only the ownership percentage. - -## Workflow - -1. Identify the finance problem and the cash-flow timing, units, currency, and risk basis. -2. Choose the exact module and function; do not invent ad hoc formulas when a kernel function exists. -3. Validate formula preconditions, especially `r > g`, positive denominators, share-count basis, and market-value weights. -4. Calculate transparently enough that the user can audit the math. -5. Return the standard Finance output format and warnings. - -## Acceptance Tests - -Run: - -```sh -python3 skills/finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py -``` - -The test suite covers DCF NPV, growing perpetuity, CAPM, WACC, VC target multiple, -post-money/pre-money, convertible note discount conversion, investor-friendly option -pool, and non-participating preferred payoff. diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/apv.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/apv.py deleted file mode 100644 index 754f2374..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/apv.py +++ /dev/null @@ -1,10 +0,0 @@ -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/bond_math.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/bond_math.py deleted file mode 100644 index bbbe83d7..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/bond_math.py +++ /dev/null @@ -1,36 +0,0 @@ -from validation import FinanceValidationError, require_positive - - -def bond_price(coupon, face_value, yield_to_maturity, periods): - if yield_to_maturity == 0: - return coupon * periods + face_value - return coupon * (1 - (1 + yield_to_maturity) ** (-periods)) / yield_to_maturity + face_value / (1 + yield_to_maturity) ** periods - - -def yield_to_maturity(price, coupon, face_value, periods, tolerance=1e-7, max_iterations=200): - require_positive("price", price) - low = -0.999999 - high = 1.0 - while bond_price(coupon, face_value, high, periods) > price and high < 1000: - high *= 2 - if high >= 1000: - raise FinanceValidationError("Yield to maturity could not be bracketed.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_price = bond_price(coupon, face_value, mid, periods) - if abs(mid_price - price) <= tolerance: - return mid - if mid_price > price: - low = mid - else: - high = mid - return (low + high) / 2 - - -def current_yield(annual_coupon, bond_price_value): - require_positive("bond_price", bond_price_value) - return annual_coupon / bond_price_value - - -def credit_spread(risky_yield, risk_free_yield): - return risky_yield - risk_free_yield diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/cap_table.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/cap_table.py deleted file mode 100644 index 73d96466..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/cap_table.py +++ /dev/null @@ -1,19 +0,0 @@ -from validation import require_positive - - -def fully_diluted_shares(common=0, preferred_as_converted=0, options_issued=0, option_pool_unissued=0, warrants=0, convertibles=0): - return common + preferred_as_converted + options_issued + option_pool_unissued + warrants + convertibles - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares - - -def dilution(old_ownership_percentage, new_ownership_percentage): - require_positive("old_ownership_percentage", old_ownership_percentage) - return 1 - new_ownership_percentage / old_ownership_percentage - - -def cap_table_sums_to_100(ownership_percentages, tolerance=1e-6): - return abs(sum(ownership_percentages) - 1) <= tolerance diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/capital_structure.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/capital_structure.py deleted file mode 100644 index e8e7565e..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/capital_structure.py +++ /dev/null @@ -1,51 +0,0 @@ -from validation import require_positive - - -def enterprise_value(equity_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return equity_value + debt + preferred_stock + minority_interest - cash - nonoperating_assets - - -def equity_value_from_ev(enterprise_value_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def debt_to_equity(debt, equity): - require_positive("equity", equity) - return debt / equity - - -def debt_to_value(debt, equity): - require_positive("debt plus equity", debt + equity) - return debt / (debt + equity) - - -def degree_of_financial_leverage(ebit, interest): - require_positive("ebit minus interest", ebit - interest) - return ebit / (ebit - interest) - - -def wacc(equity, debt, cost_of_equity, cost_of_debt, tax_rate): - total = equity + debt - require_positive("debt plus equity", total) - return equity / total * cost_of_equity + debt / total * (1 - tax_rate) * cost_of_debt - - -def mm_value_no_taxes(unlevered_value): - return unlevered_value - - -def mm_cost_of_equity_no_taxes(unlevered_cost_of_capital, cost_of_debt, debt, equity): - require_positive("equity", equity) - return unlevered_cost_of_capital + debt / equity * (unlevered_cost_of_capital - cost_of_debt) - - -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/capm.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/capm.py deleted file mode 100644 index 19a58da7..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/capm.py +++ /dev/null @@ -1,21 +0,0 @@ -from validation import require_positive - - -def capm_cost_of_equity(risk_free_rate, beta, market_risk_premium): - return risk_free_rate + beta * market_risk_premium - - -def unlever_beta(beta_l, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_l / (1 + (1 - tax_rate) * debt / equity) - - -def relever_beta(beta_u, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_u * (1 + (1 - tax_rate) * debt / equity) - - -def asset_beta_with_debt_beta(beta_equity, beta_debt, debt, equity, tax_rate=0): - require_positive("total capital", debt + equity) - tax_adjusted_debt = debt * (1 - tax_rate) - return (beta_equity * equity + beta_debt * tax_adjusted_debt) / (equity + tax_adjusted_debt) diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py deleted file mode 100644 index 9d05470a..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py +++ /dev/null @@ -1,27 +0,0 @@ -from validation import require_positive - - -def convertible_note_conversion_amount(principal, interest_rate, time, compounding_method="simple"): - if compounding_method == "simple": - return principal * (1 + interest_rate * time) - if compounding_method == "compound": - return principal * (1 + interest_rate) ** time - raise ValueError("compounding_method must be simple or compound.") - - -def convertible_note_discount_price(series_a_price, discount_rate): - return (1 - discount_rate) * series_a_price - - -def convertible_note_cap_price(valuation_cap, cap_share_count): - require_positive("cap_share_count", cap_share_count) - return valuation_cap / cap_share_count - - -def convertible_note_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def convertible_note_shares(conversion_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return conversion_amount / conversion_price diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/dcf.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/dcf.py deleted file mode 100644 index 204cb98b..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/dcf.py +++ /dev/null @@ -1,73 +0,0 @@ -from validation import FinanceValidationError, require_positive, require_rate_greater_than_growth - - -def npv(initial_investment, cash_flows, discount_rate): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def npv_with_terminal_value(initial_investment, fcfs, discount_rate, terminal_value): - return npv(initial_investment, fcfs, discount_rate) + terminal_value / (1 + discount_rate) ** len(fcfs) - - -def irr(cash_flows, tolerance=1e-7, max_iterations=200): - def value(rate): - return sum(cash_flow / (1 + rate) ** period for period, cash_flow in enumerate(cash_flows)) - - low = -0.999999 - high = 1.0 - low_value = value(low) - high_value = value(high) - while low_value * high_value > 0 and high < 1000: - high *= 2 - high_value = value(high) - if low_value * high_value > 0: - raise FinanceValidationError("IRR could not be bracketed; cash flows may have no real IRR or multiple IRRs.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_value = value(mid) - if abs(mid_value) <= tolerance: - return mid - if low_value * mid_value < 0: - high = mid - high_value = mid_value - else: - low = mid - low_value = mid_value - return (low + high) / 2 - - -def payback_period(cash_flows): - cumulative = 0 - for period, cash_flow in enumerate(cash_flows): - cumulative += cash_flow - if cumulative >= 0: - return period - return None - - -def discounted_payback_period(cash_flows, discount_rate): - discounted = [cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows)] - return payback_period(discounted) - - -def free_cash_flow(ebit, tax_rate, depreciation, capex, delta_nwc): - return ebit * (1 - tax_rate) + depreciation - capex - delta_nwc - - -def terminal_value_gordon(fcf_next, discount_rate, growth_rate): - require_rate_greater_than_growth(discount_rate, growth_rate, "discount_rate") - return fcf_next / (discount_rate - growth_rate) - - -def roic(nopat, invested_capital): - require_positive("invested_capital", invested_capital) - return nopat / invested_capital - - -def reinvestment_rate(capex, depreciation, delta_nwc, nopat): - require_positive("nopat", nopat) - return (capex - depreciation + delta_nwc) / nopat - - -def sustainable_growth(roic_value, reinvestment_rate_value): - return roic_value * reinvestment_rate_value diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/market_context.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/market_context.py deleted file mode 100644 index 7596a040..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/market_context.py +++ /dev/null @@ -1,34 +0,0 @@ -from validation import require_positive - - -def market_cap(price, shares_outstanding): - return price * shares_outstanding - - -def market_weight(company_market_cap, total_market_cap): - require_positive("total_market_cap", total_market_cap) - return company_market_cap / total_market_cap - - -def index_weight(company_market_cap, index_total_market_cap): - require_positive("index_total_market_cap", index_total_market_cap) - return company_market_cap / index_total_market_cap - - -def global_lookthrough_weight(index_weight_value, index_share_of_country_market, country_share_of_world_market): - return index_weight_value * index_share_of_country_market * country_share_of_world_market - - -def change_in_listings(start_listings, end_listings): - return end_listings - start_listings - - -def percentage_change(start_value, end_value): - require_positive("start_value", start_value) - return end_value / start_value - 1 - - -def cagr(beginning_value, ending_value, years): - require_positive("beginning_value", beginning_value) - require_positive("years", years) - return (ending_value / beginning_value) ** (1 / years) - 1 diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/option_pools.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/option_pools.py deleted file mode 100644 index e593de1a..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/option_pools.py +++ /dev/null @@ -1,22 +0,0 @@ -def investor_friendly_option_pool(existing_shares, investor_target_ownership, target_option_pool): - total_post_money_shares = existing_shares / (1 - investor_target_ownership - target_option_pool) - investor_shares = investor_target_ownership * total_post_money_shares - option_pool_shares = target_option_pool * total_post_money_shares - existing_holder_ownership = existing_shares / total_post_money_shares - return { - "total_post_money_shares": total_post_money_shares, - "investor_shares": investor_shares, - "option_pool_shares": option_pool_shares, - "existing_holder_ownership": existing_holder_ownership, - } - - -def founder_friendly_option_pool(existing_shares, investor_shares, target_option_pool): - total_post_pool_shares = (existing_shares + investor_shares) / (1 - target_option_pool) - option_pool_shares = target_option_pool * total_post_pool_shares - investor_ownership_final = investor_shares / total_post_pool_shares - return { - "total_post_pool_shares": total_post_pool_shares, - "option_pool_shares": option_pool_shares, - "investor_ownership_final": investor_ownership_final, - } diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py deleted file mode 100644 index 2906dad5..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py +++ /dev/null @@ -1,19 +0,0 @@ -def liquidation_preference(investment, liquidation_multiple=1, accrued_dividends=0): - return investment * liquidation_multiple + accrued_dividends - - -def nonparticipating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership): - return max(liquidation_preference_value, as_converted_ownership * exit_value) - - -def participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences): - if exit_value <= total_preferences: - return min(exit_value, liquidation_preference_value) - return liquidation_preference_value + as_converted_ownership * (exit_value - total_preferences) - - -def capped_participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences, cap_multiple, investment): - uncapped = participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences) - capped = min(uncapped, cap_multiple * investment) - converted = as_converted_ownership * exit_value - return max(capped, converted) diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/returns.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/returns.py deleted file mode 100644 index 7e925a81..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/returns.py +++ /dev/null @@ -1,48 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def realized_return(price_start, price_end, dividend=0): - require_positive("price_start", price_start) - return (price_end - price_start + dividend) / price_start - - -def expected_return(returns, probabilities): - require_same_length("returns", returns, "probabilities", probabilities) - return sum(probability * return_value for return_value, probability in zip(returns, probabilities)) - - -def variance(returns, probabilities): - mean = expected_return(returns, probabilities) - return sum(probability * (return_value - mean) ** 2 for return_value, probability in zip(returns, probabilities)) - - -def standard_deviation(returns, probabilities): - return sqrt(variance(returns, probabilities)) - - -def historical_average_return(returns): - require_positive("number of returns", len(returns)) - return sum(returns) / len(returns) - - -def portfolio_expected_return(weights, expected_returns): - require_same_length("weights", weights, "expected_returns", expected_returns) - return sum(weight * expected_return_value for weight, expected_return_value in zip(weights, expected_returns)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/risk.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/risk.py deleted file mode 100644 index bf065db7..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/risk.py +++ /dev/null @@ -1,41 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def portfolio_variance(weights, covariance_matrix): - rows = len(covariance_matrix) - require_same_length("weights", weights, "covariance_matrix rows", covariance_matrix) - for row in covariance_matrix: - require_same_length("weights", weights, "covariance_matrix row", row) - return sum(weights[i] * weights[j] * covariance_matrix[i][j] for i in range(rows) for j in range(rows)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) - - -def beta(asset_returns, market_returns): - market_variance = covariance(market_returns, market_returns) - require_positive("market variance", market_variance) - return covariance(asset_returns, market_returns) / market_variance - - -def estimate_beta_regression(asset_returns, market_returns, risk_free_rates): - require_same_length("asset_returns", asset_returns, "market_returns", market_returns) - require_same_length("asset_returns", asset_returns, "risk_free_rates", risk_free_rates) - excess_asset = [asset - risk_free for asset, risk_free in zip(asset_returns, risk_free_rates)] - excess_market = [market - risk_free for market, risk_free in zip(market_returns, risk_free_rates)] - return beta(excess_asset, excess_market) diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/safes.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/safes.py deleted file mode 100644 index b8fcc474..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/safes.py +++ /dev/null @@ -1,15 +0,0 @@ -from validation import require_positive - - -def safe_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def safe_shares(investment_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return investment_amount / conversion_price - - -def post_money_safe_ownership(investment_amount, post_money_valuation_cap): - require_positive("post_money_valuation_cap", post_money_valuation_cap) - return investment_amount / post_money_valuation_cap diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/time_value.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/time_value.py deleted file mode 100644 index 6d7850ba..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/time_value.py +++ /dev/null @@ -1,42 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth, require_same_length - - -def future_value(cash_flow, rate, periods): - return cash_flow * (1 + rate) ** periods - - -def present_value(cash_flow, rate, periods): - return cash_flow / (1 + rate) ** periods - - -def present_value_stream(cash_flows, rate): - return sum(present_value(cash_flow, rate, period) for period, cash_flow in enumerate(cash_flows, start=1)) - - -def present_value_with_spot_rates(cash_flows, spot_rates): - require_same_length("cash_flows", cash_flows, "spot_rates", spot_rates) - return sum(present_value(cash_flow, spot_rate, period) for period, (cash_flow, spot_rate) in enumerate(zip(cash_flows, spot_rates), start=1)) - - -def annuity_pv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * (1 - (1 + rate) ** (-periods)) / rate - - -def annuity_fv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * ((1 + rate) ** periods - 1) / rate - - -def perpetuity_pv(payment, rate): - require_positive("rate", rate) - return payment / rate - - -def growing_perpetuity_pv(next_payment, rate, growth_rate): - require_rate_greater_than_growth(rate, growth_rate) - return next_payment / (rate - growth_rate) diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/validation.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/validation.py deleted file mode 100644 index a94535ec..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/validation.py +++ /dev/null @@ -1,33 +0,0 @@ -class FinanceValidationError(ValueError): - """Raised when a finance formula cannot be applied safely.""" - - -def require_positive(name, value): - if value <= 0: - raise FinanceValidationError(f"{name} must be positive.") - return value - - -def require_nonnegative(name, value): - if value < 0: - raise FinanceValidationError(f"{name} must be nonnegative.") - return value - - -def require_rate_greater_than_growth(rate, growth_rate, rate_name="rate"): - if rate <= growth_rate: - raise FinanceValidationError(f"{rate_name} must be greater than growth rate.") - - -def require_same_length(name_a, values_a, name_b, values_b): - if len(values_a) != len(values_b): - raise FinanceValidationError(f"{name_a} and {name_b} must have the same length.") - - -def warn_if(condition, message, warnings=None): - if not condition: - return warnings if warnings is not None else [] - if warnings is None: - warnings = [] - warnings.append(message) - return warnings diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/valuation.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/valuation.py deleted file mode 100644 index 5c97d94a..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/valuation.py +++ /dev/null @@ -1,55 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth - - -def value_project_dcf(cash_flows, discount_rate, initial_investment): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def value_company_dcf(free_cash_flows, wacc, terminal_value): - return sum(fcf / (1 + wacc) ** period for period, fcf in enumerate(free_cash_flows, start=1)) + terminal_value / (1 + wacc) ** len(free_cash_flows) - - -def calculate_terminal_value_gordon(fcf_next, wacc, growth_rate): - require_rate_greater_than_growth(wacc, growth_rate, "wacc") - return fcf_next / (wacc - growth_rate) - - -def calculate_terminal_value_exit_multiple(metric, multiple): - return metric * multiple - - -def bridge_enterprise_to_equity_value(enterprise_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def calculate_price_per_share(equity_value, diluted_shares): - require_positive("diluted_shares", diluted_shares) - return equity_value / diluted_shares - - -def run_comparable_company_valuation(company_metric, comparable_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in comparable_multiples] - - -def run_precedent_transaction_valuation(company_metric, transaction_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in transaction_multiples] - - -def calculate_implied_multiple(value, metric): - require_positive("metric", metric) - return value / metric - - -def calculate_implied_value(metric, multiple): - return metric * multiple - - -def run_sensitivity_table(inputs, output_metric): - rows = [] - for case_name, case_inputs in inputs.items(): - rows.append({"case": case_name, "value": output_metric(**case_inputs)}) - return rows - - -def run_scenario_analysis(base_case, upside_case, downside_case): - return {"base": base_case, "upside": upside_case, "downside": downside_case} diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/vc_method.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/vc_method.py deleted file mode 100644 index 77d56314..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/vc_method.py +++ /dev/null @@ -1,57 +0,0 @@ -from validation import require_positive - - -def burn_rate(monthly_expenses, monthly_cash_receipts=0): - return monthly_expenses - monthly_cash_receipts - - -def runway(cash_balance, monthly_net_burn): - require_positive("monthly_net_burn", monthly_net_burn) - return cash_balance / monthly_net_burn - - -def vc_target_multiple(required_return, holding_period, probability_success): - require_positive("probability_success", probability_success) - return (1 + required_return) ** holding_period / probability_success - - -def vc_present_value(successful_exit_value, probability_success, required_return, holding_period): - return successful_exit_value * probability_success / (1 + required_return) ** holding_period - - -def vc_total_valuation(successful_exit_value, retention, target_multiple): - require_positive("target_multiple", target_multiple) - return successful_exit_value * retention / target_multiple - - -def vc_partial_valuation(proposed_ownership, total_valuation): - return proposed_ownership * total_valuation - - -def vc_required_ownership(required_investment, total_valuation): - require_positive("total_valuation", total_valuation) - return required_investment / total_valuation - - -def post_money(investment, ownership): - require_positive("ownership", ownership) - return investment / ownership - - -def pre_money(post_money_value, investment): - return post_money_value - investment - - -def price_per_share(pre_money_value, fully_diluted_pre_money_shares): - require_positive("fully_diluted_pre_money_shares", fully_diluted_pre_money_shares) - return pre_money_value / fully_diluted_pre_money_shares - - -def new_shares(investment, price_per_share_value): - require_positive("price_per_share", price_per_share_value) - return investment / price_per_share_value - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares diff --git a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/wacc.py b/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/wacc.py deleted file mode 100644 index b147c830..00000000 --- a/.claude/skills/finance-modeling-kernel/finance-modeling-kernel/wacc.py +++ /dev/null @@ -1,9 +0,0 @@ -from validation import require_positive - - -def wacc(equity_value, debt_value, cost_of_equity, cost_of_debt, tax_rate): - total_value = equity_value + debt_value - require_positive("debt plus equity", total_value) - equity_weight = equity_value / total_value - debt_weight = debt_value / total_value - return equity_weight * cost_of_equity + debt_weight * (1 - tax_rate) * cost_of_debt diff --git a/.claude/skills/financial-markets-context/SKILL.md b/.claude/skills/financial-markets-context/SKILL.md deleted file mode 100644 index 94b23ca3..00000000 --- a/.claude/skills/financial-markets-context/SKILL.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -name: financial-markets-context -description: >- - Productize Finance context skill for market capitalization, market weights, index - concentration, listed-firm trends, public-company comparables, sector shifts, and CAPM - market-portfolio assumptions. ---- - - - -# Financial Markets Context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `financial-markets-context` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings - -## Purpose - -Market context skill. Use it to interpret public-market facts, index concentration, -listed-firm trends, market capitalization, comparable-company assumptions, sector -shifts, and market portfolio assumptions in CAPM. - -## Core Formulas - -- `Market Cap_i = Share Price_i * Shares Outstanding_i` -- `Weight_i = Market Cap_i / Total Market Cap` -- `Index Weight_i = Market Cap_i / sum(Market Cap of All Index Constituents)` -- `Global Weight_i = index weight * index share of country market * country share of world market` -- `Change in Listings = Listings_End - Listings_Start` -- `% Change = (End / Start - 1) * 100` -- `CAGR = (Ending Value / Beginning Value)^(1 / Years) - 1` - -## Interpretation Rules - -- Fewer listed firms does not necessarily mean a smaller equity market. -- Market capitalization can rise even if listings fall. -- This can happen because public firms become larger, smaller firms delist, and mergers concentrate value. -- Index concentration matters because the CAPM market portfolio is value-weighted. -- Public comparables may be biased if the target is much smaller, less mature, less profitable, or in a different sector. -- Sector composition changes over time, so historical index returns may reflect sector shifts, not only broad economic growth. - -## Required Validation - -- Warn if equal weighting is confused with value weighting. -- Warn if index concentration is ignored. -- Warn if public comparables are used for a startup without maturity adjustments. -- Warn if global market assumptions use only one domestic index. -- Warn if stale market weights are used. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Separate market fact, valuation implication, and comparability risk. diff --git a/.claude/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md b/.claude/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md deleted file mode 100644 index 0fadbc11..00000000 --- a/.claude/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md +++ /dev/null @@ -1,422 +0,0 @@ ---- -name: fragmented-user-research-synthesis-into-coherent-insights -description: >- - Fragmented user research synthesis into coherent insights. Use when the user needs a product - workflow for user research related to fragmented user research synthesis into coherent - insights. Trigger terms: user-research, synthesis, insights. ---- - - - -# Fragmented user research synthesis into coherent insights - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `fragmented-user-research-synthesis-into-coherent-insights` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Fragmented user research synthesis into coherent insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{RESEARCH_INPUTS}} -- {{PRODUCT_CONTEXT}} -- {{DESIGN_QUESTIONS}} -- {{CURRENT_ASSUMPTIONS}} -- {{BUSINESS_GOALS}} - - -GOAL -Produce a high-quality deliverable for: Fragmented user research synthesis into coherent insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Synthesize fragmented research inputs into coherent, evidence-based insights that inform design and product decisions. -- Use the provided inputs: -- `{{RESEARCH_INPUTS}}` -- `{{PRODUCT_CONTEXT}}` -- `{{DESIGN_QUESTIONS}}` -- `{{CURRENT_ASSUMPTIONS}}` -- `{{BUSINESS_GOALS}}` -- Perform synthesis rigorously: -- Inventory and assess source quality/coverage. -- Extract coded observations (quotes, behaviors, themes, segment/context metadata). -- Identify cross-source patterns and contradictions. -- Assign confidence levels with explicit rationale. -- Map insights to JTBD and user-needs hierarchy. -- Link insights directly to design questions and actionable recommendations. -- Identify research gaps, unresolved assumptions, and prioritized follow-up research. -- Keep evidence traceable, avoid over-generalization, and state assumptions/uncertainties explicitly. - -FORMAT -Return exactly this structure: - - - -**Data Sources Summary:** -- User interviews: [X participants] covering [topics, user segments, dates] -- Support tickets: [Y tickets] from [date range] about [primary themes] -- NPS feedback: [Z responses] with [average score] discussing [key topics] -- Usage analytics: [data range, key metrics, user actions analyzed] -- Feature requests: [count] requests across [platforms/sources] -- Usability tests: [sessions count] testing [specific flows or features] -- Survey data: [respondents count] on [topics covered] -- Anecdotal feedback: [source count] from [stakeholders, channels] -- Session recordings: [count] sessions showing [behaviors] -- Other sources: [specify any additional data] - -**Data Quality Assessment:** -- Time range: [how recent is this data?] -- User segment coverage: [which personas/segments are represented?] -- Sample size adequacy: [sufficient for confidence in findings?] -- Potential bias: [what perspectives might be over/under-represented?] -- Data completeness: [what's missing or sparse?] - - - - -**Insight Statement:** -[One clear, specific sentence stating what you learned about users] - -**Evidence:** -- User interviews: "[verbatim quote]" (Participant X, [segment]) -- Support tickets: [Y tickets] report "[specific issue]" with keywords: [terms] -- NPS feedback: "[example comment]" (common theme in Z% of detractor responses) -- Analytics data: [X% of users] exhibit [specific behavior], [frequency/context] -- Additional evidence: [any other supporting data points] - -**Confidence Level:** High / Medium / Low -**Rationale for Confidence:** [Why you assigned this confidence level] - -**User Segments Affected:** -- [Segment 1]: [how this manifests for them] -- [Segment 2]: [how this manifests for them] - -**Jobs-to-be-Done Connection:** -[Which job is this insight related to? How does it help or hinder job completion?] - -**Design Implications:** -- Consider: [specific design approach this suggests] -- Avoid: [what this insight argues against] -- Prioritize: [which aspect of the experience to focus on] -- Measure: [how to validate design addressed this insight] - -**Related Patterns:** -[Which other insights connect to this? How do they reinforce or complicate each other?] - -**Business Impact:** -[How does addressing this insight connect to business goals or metrics?] - - - -[Repeat the full structure for 5-10 key insights, maintaining consistent depth and evidence rigor] - - - -[Continue for all major insights...] - - - - -**Conflict 1:** -- Signal A: [what one source or segment indicates] -- Signal B: [what contradicts this] -- Possible explanations: - * [Explanation 1: e.g., different user segments with different needs] - * [Explanation 2: e.g., stated preference vs. actual behavior] - * [Explanation 3: e.g., context-dependent variation] -- Recommended resolution: [What research or analysis would clarify this?] -- Design strategy given conflict: [How to proceed despite uncertainty?] - -**Conflict 2:** -[Repeat structure for each major contradiction in the data] - -**Synthesis:** -[What do these conflicts reveal about user diversity, product complexity, or research gaps?] - - - -**Question 1:** [Restate the first design question] -- **Answer based on research:** [What the data tells you] -- **Supporting insights:** [Which insights from above inform this answer] -- **Confidence level:** High / Medium / Low -- **Caveats and limitations:** [What qualifies or nuances this answer] -- **What we still don't know:** [Gaps specific to this question] -- **Recommended action:** [What to design/test/research next] - -**Question 2:** [Restate the second design question] -[Repeat structure for each design question provided] - -**New Questions Surfaced:** -[Design questions that emerged from the research but weren't originally asked] - - - - -**Must-Have Needs (Strong Evidence, High Impact):** -1. [Need 1]: [description] - - Evidence: [cross-source validation] - - If unmet: [severe user/business consequence] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat structure for 3-5 critical needs] - - - -**Should-Have Needs (Moderate Evidence, Meaningful Impact):** -1. [Need 1]: [description] - - Evidence: [validation from 1-2 strong sources] - - If unmet: [moderate user friction or business impact] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat for 5-8 important needs] - - - -**Nice-to-Have Needs (Weak Signal, Low/Uncertain Impact):** -1. [Need 1]: [description] - - Evidence: [limited mentions or single source] - - Potential value: [why this might matter despite weak signal] - - Validation needed: [how to test if this is actually important] - -2. [Need 2]: [description] - [Repeat for 3-5 nice-to-have needs] - - - -**Segment-Specific Needs:** -- [Segment A]: [unique needs not shared by other segments] -- [Segment B]: [unique needs not shared by other segments] -- [Universal needs]: [needs expressed across all segments] - - - - -**Current Workflows and Workarounds:** -[Describe how users actually accomplish tasks today, including inefficient or creative workarounds that reveal unmet needs] - -**Decision-Making Patterns:** -[How users make choices within the product, what information they seek, what causes hesitation or confidence] - -**Pain Point Triggers:** -[Specific circumstances, contexts, or actions that consistently lead to user frustration] - -**Success Patterns:** -[When and how users successfully achieve their goals, what enables their success] - -**Usage Context and Frequency:** -[When, where, why, and how often users engage with the product or specific features] - -**Adoption and Learning Patterns:** -[How users onboard themselves, what helps or hinders learning, common confusion points] - -**Abandonment and Recovery Patterns:** -[What causes users to give up, what brings them back, how they recover from errors] - -**Cross-Tool Workflows:** -[How users combine your product with other tools, what gaps force tool-switching] - - - -**Primary Functional Jobs:** -1. [Job]: When [situation], I want to [motivation], so I can [expected outcome] - - Evidence: [how research revealed this job] - - Current obstacles: [what prevents job completion] - - Success criteria: [how users define successful job completion] - -2. [Job]: [Repeat structure for 3-5 primary jobs] - -**Emotional Jobs:** -- [Feel]: [emotion users want to feel, e.g., "feel confident in my decisions"] -- [Avoid]: [emotion users want to avoid, e.g., "avoid feeling overwhelmed"] -- Evidence: [quotes, observations, sentiment indicators] - -**Social Jobs:** -- [Perception]: [how users want to be seen, e.g., "be perceived as data-driven"] -- [Context]: [social situations where product use matters] -- Evidence: [research indicators of social motivations] - -**Related Jobs in the Consumption Chain:** -- Before main job: [how users discover, evaluate, and choose the product] -- After main job: [how users share, report, or build on outcomes] -- Maintenance jobs: [ongoing tasks to keep getting value] - - - - -**Critical Unknowns (Blocking Design Decisions):** -1. [Question]: [why this matters for design] -2. [Question]: [why this matters for design] -3. [Question]: [why this matters for design] - -**Important Unknowns (Would Significantly Inform Design):** -1. [Question]: [how this would help] -2. [Question]: [how this would help] - -**Curiosities (Interesting But Not Urgent):** -1. [Question]: [potential value] -2. [Question]: [potential value] - - - -**Research Activity 1:** -- **Method:** [interviews / usability testing / survey / analytics deep-dive / diary study / etc.] -- **Target participants:** [which user segments, how many, recruitment criteria] -- **Key questions to answer:** [specific questions this research would resolve] -- **Expected outcomes:** [what you'll learn and how it informs design] -- **Effort estimate:** [time and resources required] -- **Priority:** High / Medium / Low - [rationale] - -**Research Activity 2:** -[Repeat structure for 3-5 recommended research activities, prioritized by impact and urgency] - - - -**Design Assumptions:** -1. [Assumption about user behavior or preferences]: Currently [validated / unvalidated / contradicted] by research -2. [Assumption about priorities or needs]: Currently [status] -3. [Assumption about technical or business constraints]: Currently [status] - -**Team Assumptions:** -[Assumptions stakeholders or team members hold that aren't supported by dataโ€”list with gentle evidence-based reframing] - -**Testing Strategy:** -[How to quickly validate or invalidate the most critical assumptions through lightweight tests] - - - - -**Priority 1 Recommendations (Supported by High-Confidence Insights):** -1. [Specific design action]: [rationale tied to insight X, Y, Z] - - Expected impact: [user and business outcomes] - - Success metrics: [how to measure if this worked] - -2. [Specific design action]: [rationale tied to insights] - [Repeat for 3-5 top-priority recommendations] - -**Priority 2 Recommendations (Supported by Medium-Confidence Insights):** -1. [Specific design action]: [rationale] - [Repeat for 5-7 secondary recommendations] - -**Quick Wins (Low Effort, Clear User Value):** -1. [Specific design action]: [why this is easy and valuable] - [Repeat for 3-5 quick wins] - -**Strategic Bets (Lower Confidence, High Potential):** -1. [Specific design action]: [why worth exploring despite uncertainty] - - Validation approach: [how to test before full commitment] - [Repeat for 2-3 strategic bets] - -**Do Not Pursue:** -[Features, changes, or directions that research argues against, with rationale] - - - -**Executive Summary** - -**What We Learned:** -[2-3 sentences capturing the most important insights from the research] - -**User Needs Priority:** -Users critically need [top need], strongly want [second need], and would appreciate [third need]. The evidence is strongest for [insight area] and weakest for [insight area requiring validation]. - -**Key Behavioral Patterns:** -[1-2 sentences on how users actually behave vs. what we might have assumed] - -**Design Implications:** -The research strongly supports [recommended direction 1] and [recommended direction 2], while arguing against [current assumption or planned direction]. We should prioritize [specific user segment or job-to-be-done] because [evidence-based rationale]. - -**Critical Unknowns:** -We still need to understand [key gap 1] and [key gap 2] through [recommended research method]. - -**Recommended Next Steps:** -1. [Immediate action based on high-confidence insights] -2. [Design exploration for medium-confidence opportunities] -3. [Targeted research to fill critical gaps] - -**Business Impact:** -Addressing these insights is expected to improve [business metric] by [directional estimate] because [user behavior change expected]. - -[Total: 250-350 words] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Insights are not supported by cross-source evidence or confidence rationale. -- Contradictions are ignored or not addressed with a resolution approach. -- Recommendations are not prioritized or not linked to synthesized insights/business goals. -- Research gaps and assumption validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/framework-application-to-product-challenges-from-user-input/SKILL.md b/.claude/skills/framework-application-to-product-challenges-from-user-input/SKILL.md deleted file mode 100644 index ac6f1c56..00000000 --- a/.claude/skills/framework-application-to-product-challenges-from-user-input/SKILL.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -name: framework-application-to-product-challenges-from-user-input -description: >- - Framework application to product challenges from user input. Use when the user needs a - product workflow for product strategy related to framework application to product challenges - from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching. ---- - - - -# Framework application to product challenges from user input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `framework-application-to-product-challenges-from-user-input` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Framework application to product challenges from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRAMEWORK}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Framework application to product challenges from user input. -Success metric: -- Asks targeted questions when key context is missing. -- Applies the provided framework precisely to the userโ€™s situation. -- Produces actionable advice and a clear recommendation when sufficient context exists. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{FRAMEWORK}}` and `{{USER_INPUT}}`; if key context is missing, ask targeted questions first. -- Do not summarize the framework back to the user. -- When asking for more information, use `` tags only. -- When providing guidance, use `` tags only. -- When providing a final recommendation, use `` tags only. -- Keep advice specific and grounded in the userโ€™s context; avoid generic PM guidance. - -FORMAT -Return exactly this structure: - - -[Targeted questions needed to apply the framework] - - - -[Framework-applied guidance once sufficient context exists] - - - -[Final recommendation when enough context exists] - - -FAILURE -- Required tags are missing or malformed. -- Output includes framework summary instead of application. -- Advice is generic or not tied to the user input. -- Recommendation is provided without sufficient context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/frontend-design/SKILL.md b/.claude/skills/frontend-design/SKILL.md deleted file mode 100644 index 7c052af4..00000000 --- a/.claude/skills/frontend-design/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: frontend-design -description: >- - Design implementation-ready frontend solutions with UX intent, component structure, - responsive behavior, accessibility, and handoff criteria. ---- - - - -# Frontend Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `frontend-design` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to design frontend behavior and UI structure before or alongside implementation. - -## The Process - -### Step 1: Define UX objective - -Capture: -- user goal -- primary user flow -- success state and failure states - -### Step 2: Specify UI architecture - -Define: -- screen/layout structure -- component hierarchy -- state model (loading, empty, error, success) - -### Step 3: Specify design system decisions - -Set: -- typography and spacing rules -- color/contrast constraints -- interaction patterns - -### Step 4: Specify responsive and accessibility requirements - -Include: -- breakpoints and behavior changes -- keyboard navigation expectations -- ARIA/semantic requirements -- contrast and focus visibility requirements - -### Step 5: Define implementation handoff - -Provide: -- component list and props/state contract -- acceptance criteria -- verification checklist - -## Output Format - -```markdown -# [Feature Name] Frontend Design Spec - -## UX Objective -- User goal: -- Primary flow: -- Success/failure states: - -## UI Architecture -- Layout: -- Component hierarchy: -- State model: - -## Responsive Behavior -- Desktop: -- Tablet: -- Mobile: - -## Accessibility Requirements -- Keyboard: -- Semantics/ARIA: -- Contrast/focus: - -## Handoff -- Components to implement: -- Acceptance criteria: -- Verification checklist: -``` - -## Quality Bar - -- Design decisions must map to user goals -- Accessibility section is mandatory -- Handoff must be implementable without extra interpretation - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/.claude/skills/future-product-opportunities-from-market-inflection-points/SKILL.md b/.claude/skills/future-product-opportunities-from-market-inflection-points/SKILL.md deleted file mode 100644 index 508e76c8..00000000 --- a/.claude/skills/future-product-opportunities-from-market-inflection-points/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: future-product-opportunities-from-market-inflection-points -description: >- - Future product opportunities from market inflection points. Use when the user needs a - product workflow for product strategy related to future product opportunities from market - inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, - trends, product-vision. ---- - - - -# Future product opportunities from market inflection points - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `future-product-opportunities-from-market-inflection-points` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Future product opportunities from market inflection points**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_YEAR}} -- {{RESEARCH_TIMEFRAME}} - - -GOAL -Produce a high-quality deliverable for: Future product opportunities from market inflection points. -Success metric: -- Identifies concrete regulatory, technological, and belief inflection points within the stated timeframe. -- Connects converging trends to 3โ€“5 plausible future opportunities. -- Provides actionable challenges and timelines for each opportunity. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_YEAR}}` and `{{RESEARCH_TIMEFRAME}}`; if context is missing, state assumptions explicitly. -- List 3โ€“5 items per inflection category (regulatory, technological, belief). -- Provide 3โ€“5 converging trend sets that explicitly combine at least two categories. -- Provide 3โ€“5 future opportunities with concept, enabling trends, challenges, and timeline. -- Keep opportunities plausible within the specified research timeframe. - -FORMAT -Return exactly this structure: - - -1. Inflection Points: - a. Regulatory: - - [List 3โ€“5 significant regulatory changes] - b. Technological: - - [List 3โ€“5 important technological advancements] - c. Belief: - - [List 3โ€“5 notable shifts in societal attitudes or behaviors] - -2. Converging Trends: - - [Describe 3โ€“5 sets of converging trends, explaining how they intersect] - -3. Future Opportunities: - [For each opportunity (aim for 3โ€“5), include:] - a. Concept: [Brief description] - b. Enabling Trends: [List the key inflection points or converging trends] - c. Challenges: [Potential barriers or difficulties] - d. Timeline: [Estimated timeframe for realization] - -4. Conclusion: - [Summarize the most promising areas for innovation based on your analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any inflection category has fewer than 3 or more than 5 items. -- Converging trends do not combine multiple categories. -- Opportunities are missing required fields or outside the specified timeframe. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/group-decision-making-quality-review/SKILL.md b/.claude/skills/group-decision-making-quality-review/SKILL.md deleted file mode 100644 index 550aafd9..00000000 --- a/.claude/skills/group-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, or - operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group - decides. ---- - - - -# Group Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `group-decision-making-quality-review` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/.claude/skills/grow/SKILL.md b/.claude/skills/grow/SKILL.md deleted file mode 100644 index 7a27ee80..00000000 --- a/.claude/skills/grow/SKILL.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: grow -description: >- - Productize grow playbook for stable products with activation evidence. Use when the product - has a working core and the team needs growth diagnosis, growth loops, GTM choices, - onboarding, retention, pricing, lifecycle triggers, and experiment cadence. ---- - - - -# Productize Grow - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `grow` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition - -Use this playbook when the core product is stable enough to grow. Grow is not the -place to invent the product; use `$0-1` for new bets and `$operate` for continuous -production health. - -## Cadence - -- Trigger: stable activation, repeat usage, clear ICP, or a growth bottleneck. -- Rhythm: weekly experiment planning and readout, with metric reviews before changing - channels, onboarding, pricing, or lifecycle triggers. -- Closure: target hit, target abandoned, strategy pivot, or evidence that the product - needs a new `$0-1` loop. - -## Route Internally - -- Product-market fit and bottlenecks: `$product-market-fit-cycle`, `$aarrr-growth-diagnostics`, `$metrics-review` -- Loops and experiments: `$growth-loops`, `$plg-growth-playbook`, `$growth-project-generation-with-pioneer-migrator-settler`, `$robust-experiment-design-from-goals-and-systems` -- GTM and lifecycle: `$gtm-motions`, `$gtm-strategy`, `$onboarding-flow-optimization-from-product-data-to-user-success` -- Retention and monetization: `$churn-reduction-from-customer-data-and-exit-survey-analysis`, `$pricing-strategy`, `$monetization-strategy` -- Gates: `$product-review`, `$qa`, `$comms-review`, `$docs`, `$release` - -## Required Output - -Return: - -1. **Growth State**: ICP, activation evidence, retention signal, bottleneck, and metric caveats. -2. **Growth Thesis**: target, growth loop, channel or lifecycle trigger, and why it fits the current evidence. -3. **Experiment Cadence**: tests, owners, sample size or evidence threshold, and stop/pivot rules. -4. **Gate Calls**: product, QA, docs, release, or comms gates needed before launch. -5. **Closure Condition**: target hit, pivot, pause, or new `$0-1` bet. diff --git a/.claude/skills/growth-loops/SKILL.md b/.claude/skills/growth-loops/SKILL.md deleted file mode 100644 index 3e589edd..00000000 --- a/.claude/skills/growth-loops/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- - - - -# Growth Loops - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-loops` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md b/.claude/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md deleted file mode 100644 index 951415fa..00000000 --- a/.claude/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: growth-project-generation-with-pioneer-migrator-settler -description: >- - Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a - product workflow for product strategy related to growth project generation with - pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, - portfolio. ---- - - - -# Growth project generation with Pioneer-Migrator-Settler framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-project-generation-with-pioneer-migrator-settler` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Growth project generation with Pioneer-Migrator-Settler framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY}} - - -GOAL -Produce a high-quality deliverable for: Growth project generation with Pioneer-Migrator-Settler framework. -Success metric: -- Produces 12 distinct growth projects categorized into Pioneer/Migrator/Settler. -- Ensures balanced portfolio logic and a brief plan to drive growth. -- Keeps ideas concrete, differentiated, and aligned to the company context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY}}`; if details are missing, state assumptions explicitly. -- Generate exactly 12 distinct growth projects: - - 3 creative, - - 3 weird, - - 3 compelling, - - 3 novel and unexpected. -- Each idea must be tagged as one of: Pioneer, Migrator, Settler. -- Keep ideas concrete and specific to the companyโ€™s context. -- Provide a brief analysis of portfolio balance and strategic impact. -- Provide a short growth plan for how to build new market space and profitable growth. - -FORMAT -Return exactly this structure: - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - - -[Brief analysis of mix and impact, with portfolio balance insights] - - - -[Brief plan for creating new market space and profitable growth] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer or more than 12 ideas are provided. -- Any idea is missing a Pioneer/Migrator/Settler category. -- Ideas are generic or not grounded in the company context. -- Analysis or growth plan is missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md b/.claude/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md deleted file mode 100644 index 74929fac..00000000 --- a/.claude/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: growth-strategy-synthesis-from-user-inputs -description: >- - Growth strategy synthesis from user inputs. Use when the user needs a product workflow for - product strategy related to growth strategy synthesis from user inputs. Trigger terms: - growth, strategy, experimentation, metrics, distribution. ---- - - - -# Growth strategy synthesis from user inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-strategy-synthesis-from-user-inputs` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth strategy brief with bets, loops, experiments, and metrics - -Use this skill to run the Productize prompt contract for **Growth strategy synthesis from user inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUTS}} - - -GOAL -Produce a high-quality deliverable for: Growth strategy synthesis from user inputs. -Success metric: -- Produces a complete growth strategy across model, constraints, horizon, method, principle, and catalyst. -- Grounds all recommendations in the provided user inputs. -- Outputs actionable, testable recommendations and a concise summary. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUTS}}`; if critical data is missing, state assumptions explicitly. -- Address each required section: model, constraint, horizon, method, principle, catalyst, summary. -- Keep recommendations actionable and testable; avoid generic advice. -- If quantitative data is present, reference it; if not, use qualitative reasoning and label assumptions. - -FORMAT -Return exactly this structure: - - - -[Provide a detailed description of the growth model] - - - -[Identify and explain the main growth constraints] - - - -[Analyze the growth horizon and potential limitations] - - - -[Propose specific methods to address constraints and extend the growth horizon] - - - -[Develop a guiding principle for aligning the organization] - - - -[Identify and explain any growth catalysts] - - - -[Provide a brief summary of the overall growth strategy] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Recommendations are not tied to the provided inputs. -- Growth method lacks actionable steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/gtm-motions/SKILL.md b/.claude/skills/gtm-motions/SKILL.md deleted file mode 100644 index 8c436e2f..00000000 --- a/.claude/skills/gtm-motions/SKILL.md +++ /dev/null @@ -1,236 +0,0 @@ ---- -name: gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, - partner, ABM, or hybrid go-to-market motions. ---- - - - -# GTM Motions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-motions` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/gtm-strategy/SKILL.md b/.claude/skills/gtm-strategy/SKILL.md deleted file mode 100644 index eed10337..00000000 --- a/.claude/skills/gtm-strategy/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- - - - -# GTM Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md b/.claude/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md deleted file mode 100644 index af1e4586..00000000 --- a/.claude/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- - - - -# Ideal Customer Profile (ICP) representative for X product - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideal-customer-profile-icp-representative-for-x-product` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.claude/skills/ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md b/.claude/skills/ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md deleted file mode 100644 index 3be9171c..00000000 --- a/.claude/skills/ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md +++ /dev/null @@ -1,171 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make ICP outputs sharper on demographics, behaviors, JTBD, PMF evidence, and best-customer patterns. - -## Routing Signals - -- ideal customer profile -- icp -- pmf survey -- best customers - -## pm-go-to-market/skills/ideal-customer-profile/SKILL.md - -## Overview -Identify your Ideal Customer Profile (ICP) from research and survey data. This skill synthesizes customer research to define the customer most likely to find value, retain, and expand with your product. - -## When to Use -- Defining ICP from product-market fit survey data -- Targeting high-value customer segments -- Analyzing customer success and expansion patterns -- Prioritizing sales and marketing efforts -- Evaluating new customer opportunities for fit -- Refining target market definition - -## ICP Framework Components - -### Demographics -Who are they from a firmographic and personal perspective? -- Company size (employees, revenue) -- Industry or vertical -- Geographic location -- Job title and department -- Years of experience in role -- Education and background -- Organizational structure and reporting - -### Behaviors -How do they work and make decisions? -- How they discover and evaluate solutions -- Buying process and decision-making timeline -- Technical literacy and product adoption speed -- Collaboration style (solo decision vs committee) -- Change management and adoption style -- Tool switching frequency -- Community involvement and peer influence - -### Jobs to Be Done (JTBD) -What are they trying to accomplish? -- Primary job/goal they're trying to achieve -- Secondary jobs that support the primary job -- Emotional jobs (how they want to feel) -- Social jobs (status and perception) -- Jobs they avoid or want to eliminate -- Frequency and importance of each job -- Success metrics for completing job - -### Needs and Pain Points -What problems does your product solve? -- Specific pain points they experience -- Current workarounds and limitations -- Impact on productivity or outcomes -- Cost or time burden of the problem -- Emotional frustration levels -- Barriers to solving the problem -- Available budget to solve -- Competing priorities - -## How It Works - -### Step 1: Gather Customer Data -Collect research about actual and potential customers: -- Product-market fit survey responses -- Customer interview transcripts -- Trial or freemium user behavior data -- Customer feedback and support tickets -- Churn analysis and customer lifecycle data -- Win/loss analysis from sales -- Competitor customer analysis - -### Step 2: Segment by Value -Identify customer cohorts and their value: -- Highest LTV (lifetime value) customers -- Fastest time-to-value customers -- Lowest churn rate customers -- Highest expansion/upsell customers -- Most enthusiastic/engaged customers -- Best reference/case study potential -- Most aligned with product vision - -### Step 3: Profile Demographics -Extract firmographic patterns: -- Common company sizes (employee count, revenue) -- Industry verticals and sub-verticals -- Geographic concentrations -- Typical department and reporting structure -- Budget holders and budget available -- Company stage (startup, growth, enterprise) -- Company culture indicators - -### Step 4: Identify Behaviors -Map decision-making and adoption patterns: -- How they discovered your product (channel) -- Evaluation process and timeline -- Key stakeholders in decision -- Obstacles during sales process -- Product adoption speed and breadth -- Team involvement in onboarding -- Frequency of feature usage -- Support and service needs - -### Step 5: Define JTBD -Articulate what they're trying to accomplish: -- Primary job/goal (functional job) -- Emotional dimensions (how they want to feel) -- Social dimensions (team and stakeholder impact) -- Success metrics (how they measure success) -- Context and constraints (when, where, with whom) -- Competing jobs and priorities -- Importance ranking of various jobs - -### Step 6: Document Pain Points and Needs -Synthesize specific problem areas: -- Before state (current situation and frustrations) -- Desired after state (ideal future state) -- Gap size and impact quantification -- Emotional dimensions of the problem -- Resource constraints preventing solutions -- Skepticism or hesitations -- Success criteria for solution - -## Input Format -Use $ARGUMENTS to pass: -- Research data (surveys, interviews, transcripts) -- Customer success/metrics data -- Product usage analytics -- Sales activity and win/loss data -- Existing customer database -- Competitive intelligence - -## Output -A comprehensive ICP definition including: -- Firmographic profile (company size, industry, location) -- Behavioral profile (buying patterns, adoption style) -- Complete JTBD mapping (functional, emotional, social jobs) -- Top 5-7 pain points and specific needs -- Quantified impact metrics (cost of problem, value of solution) -- Decision-making process and key stakeholders -- Typical customer journey and timeline -- Go-to-market implications and messaging -- Disqualification criteria (who is NOT a good fit) -- High-value segment within ICP (ideal-of-the-ideal) - -## Framework -Based on Jobs to Be Done theory by Clayton Christensen and customer profiling methodology. Combines behavioral data with motivational insights to define actionable customer profiles. - -## Tips -- Use quantitative and qualitative data together -- Interview 10+ high-value customers for pattern identification -- Look for non-obvious demographic patterns (outliers can be high-value) -- Define both ideal ICP and acceptable secondary segments -- Revisit ICP quarterly as you gather more customer data -- Use ICP to evaluate all new sales opportunities -- Share ICP across entire organization (marketing, sales, product) -- Remember: ICP should drive focus, not exclude all others - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/.claude/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md b/.claude/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md deleted file mode 100644 index d08f9913..00000000 --- a/.claude/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: ideas-for-affordances-and-signifiers-based-on-a-design-problem -description: >- - Ideas for affordances and signifiers based on a design problem. Use when the user needs a - product workflow for design & prototyping related to ideas for affordances and signifiers - based on a design problem. Trigger terms: ux, interaction-design, affordances, usability. ---- - - - -# Ideas for affordances and signifiers based on a design problem - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideas-for-affordances-and-signifiers-based-on-a-design-problem` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Ideas for affordances and signifiers based on a design problem**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_CHALLENGE}} - - -GOAL -Produce a high-quality deliverable for: Ideas for affordances and signifiers based on a design problem. -Success metric: -- Identifies key user interactions in the design challenge before proposing ideas. -- Produces at least 5 concrete ideas each for affordances, perceived affordances, and signifiers. -- Each idea includes a brief explanation tied to the challenge and UX impact. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DESIGN_CHALLENGE}}`; if context is incomplete, state assumptions explicitly. -- Start with a brief interaction analysis identifying main user functions/tasks. -- Generate at least 5 ideas in each category: affordances, perceived affordances, signifiers. -- For every idea, include a short explanation linking: - - the specific challenge friction/opportunity, - - how the idea guides user action or perception, - - expected UX improvement. -- Keep ideas practical, non-generic, and directly relevant to the described product context. - -FORMAT -Return exactly this structure: - - - -[Main user interactions/functions required by the challenge] - - - -1. [Affordance idea] - [Brief explanation] -2. [Affordance idea] - [Brief explanation] -3. [Affordance idea] - [Brief explanation] -4. [Affordance idea] - [Brief explanation] -5. [Affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Perceived affordance idea] - [Brief explanation] -2. [Perceived affordance idea] - [Brief explanation] -3. [Perceived affordance idea] - [Brief explanation] -4. [Perceived affordance idea] - [Brief explanation] -5. [Perceived affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Signifier idea] - [Brief explanation] -2. [Signifier idea] - [Brief explanation] -3. [Signifier idea] - [Brief explanation] -4. [Signifier idea] - [Brief explanation] -5. [Signifier idea] - [Brief explanation] -[Optional additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 5 ideas in any required category. -- Explanations are missing for one or more ideas. -- No interaction analysis is provided before idea lists. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/implementation-notes/SKILL.md b/.claude/skills/implementation-notes/SKILL.md deleted file mode 100644 index 609f2360..00000000 --- a/.claude/skills/implementation-notes/SKILL.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: implementation-notes -description: >- - Running implementation-notes protocol for spec-driven builds. Use when the user asks the - agent to maintain implementation-notes.md or implementation-notes.html with decisions, - deviations, tradeoffs, open questions, and verification while implementing a feature, fix, - or product slice. ---- - - - -# Implementation Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `implementation-notes` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence - -Use this skill when implementation work needs a durable notes artifact that keeps -the user in the loop without stopping progress for every ambiguity. - -This is not a verbose work log. It records the meaningful places where the spec -was interpreted, narrowed, changed, or found incomplete. - -## Activation - -Activate alongside `$tdd`, `$eng-review`, `$qa`, or `$verification` when the user -asks for any of: - -- `implementation-notes.md` -- `implementation-notes.html` -- running implementation notes -- decisions the spec did not cover -- deviations from the spec -- tradeoffs made during implementation -- open questions to confirm after implementation - -Do not ask whether to create the file if the user already requested it. Create or -update the requested file and keep working. - -## File Selection - -- Use the exact path and format the user requested. -- If the user asks for notes but does not name a file, use `implementation-notes.md`. -- If the user asks for HTML, use `implementation-notes.html`. -- If an implementation-notes file already exists for the current task, update it - instead of overwriting useful existing context. - -## Update Cadence - -1. Create the notes file before or during the first implementation decision. -2. Update it when the implementation makes a non-obvious choice, interprets an - ambiguous spec line, departs from the spec, accepts a tradeoff, discovers an - open question, or changes verification scope. -3. Batch small related choices into one entry instead of writing noisy micro-logs. -4. Before claiming completion, do a final pass that aligns notes with the actual - diff, verification evidence, and unresolved questions. - -## What To Capture - -### Design Decisions - -Choices made where the spec was ambiguous or silent. - -Each entry should include: - -- decision -- reason -- spec basis, or `unspecified` -- impact - -### Deviations - -Intentional departures from the spec. - -Each entry should include: - -- requested behavior -- implemented behavior -- reason -- impact -- whether user confirmation is needed - -### Tradeoffs - -Alternatives considered and why the chosen path is better for this slice. - -Each entry should include: - -- chosen option -- alternatives considered -- why chosen -- cost or downside accepted - -### Open Questions - -Questions the user may want to confirm or revise. - -Each entry should include: - -- question -- why it matters -- current default assumption -- status: `needs-review`, `accepted-risk`, `resolved`, or `deferred` - -### Verification - -Evidence that proves the implementation and the notes are current. - -Include: - -- commands or checks run -- result -- coverage gaps -- behavior not tested - -## What Not To Capture - -- Every file edit. -- Internal reasoning or chain-of-thought. -- Obvious implementation details already specified. -- Secrets, credentials, private customer data, or raw logs with sensitive content. -- Generic progress narration that does not help the user review decisions. - -## Markdown Template - -Use this structure for Markdown notes: - -```markdown -# Implementation Notes - -## Spec Reference -[Feature, ticket, prompt, or artifact being implemented.] - -## Summary -[One paragraph describing how the implementation interprets the spec.] - -## Design Decisions -| Decision | Reason | Spec basis | Impact | -|---|---|---|---| - -## Deviations -| Requested | Implemented | Why | Impact | Confirmation | -|---|---|---|---|---| - -## Tradeoffs -| Choice | Alternatives | Why this path | Downside | -|---|---|---|---| - -## Open Questions -| Question | Why it matters | Current assumption | Status | -|---|---|---|---| - -## Verification -| Check | Result | Notes | -|---|---|---| -``` - -## HTML Template Rules - -For `implementation-notes.html`, produce a single self-contained HTML file: - -- embedded CSS and JavaScript only -- no external assets or remote dependencies unless explicitly requested -- semantic headings and landmarks -- responsive layout -- decision cards or tables for scanability -- status chips for `needs-review`, `accepted-risk`, `resolved`, and `deferred` -- a clear verification section near the bottom -- optional filters, collapsible detail, or copy buttons only when they help review - -Recommended HTML sections: - -1. **Header**: spec reference, implementation status, last updated, owner if known. -2. **Decision Dashboard**: counts for decisions, deviations, tradeoffs, open questions. -3. **Design Decisions**: cards or table with reason, spec basis, and impact. -4. **Deviations**: requested vs implemented, why, impact, confirmation status. -5. **Tradeoffs**: comparison table with accepted downside. -6. **Open Questions**: status and current default assumption. -7. **Verification**: commands/checks, results, and gaps. - -## Route Internally - -- `$tdd` -- `$eng-review` -- `$qa` -- `$verification` -- `$docs` -- `$release` - -## Required Output - -Return: - -1. **Notes File**: path, format, and whether it was created or updated. -2. **Captured Decisions**: decisions, deviations, tradeoffs, and open questions added. -3. **Spec Impact**: what downstream product, design, eng, QA, release, docs, or DX work may change. -4. **Verification Linkage**: checks run, gaps, and whether the notes match the final implementation. -5. **Next Review**: user confirmations or gate follow-ups needed. diff --git a/.claude/skills/industry-trend-strategy/SKILL.md b/.claude/skills/industry-trend-strategy/SKILL.md deleted file mode 100644 index becc8af7..00000000 --- a/.claude/skills/industry-trend-strategy/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: industry-trend-strategy -description: >- - Industry trend strategy. Use when the user needs a product workflow for product strategy - related to industry trend strategy. Trigger terms: strategy, competitive-analysis, - positioning, decision-making. ---- - - - -# Industry trend strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `industry-trend-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Industry trend strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INDUSTRY}} -- {{TREND}} -- {{COMPANY}} -- {{GOAL}} - - -GOAL -Produce a high-quality deliverable for: Industry trend strategy. -Success metric: -- Produces a grounded industry + trend analysis tied to company strengths and goal. -- Proposes at least three distinct strategies with actionable steps. -- Summarizes how strategies leverage strengths to achieve the goal. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{INDUSTRY}}`, `{{TREND}}`, `{{COMPANY}}`, and `{{GOAL}}`; if critical data is missing, state assumptions explicitly. -- Provide a concise industry + trend analysis and a focused company strengths assessment. -- Propose at least 3 distinct strategies aligned to strengths and goal. -- Each strategy must include name, description, alignment, contribution to goal, challenges, and action steps. -- Keep recommendations specific and actionable, not generic. - -FORMAT -Return exactly this structure: - - -[Industry + trend analysis and company strength assessment] - - - -1. [Strategy name] - - Description: [What it is] - - Alignment: [Company strengths leveraged] - - Contribution to goal: [How it advances the goal] - - Challenges: [Risks/obstacles] - - Action steps: [Concrete steps] -2. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -3. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -[Optional additional strategies] - - - -[Summary emphasizing how strategies leverage strengths to capitalize on the trend and achieve the goal] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 strategies are provided. -- Strategies lack alignment to company strengths or contribution to goal. -- Action steps are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md b/.claude/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md deleted file mode 100644 index 8339ff15..00000000 --- a/.claude/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: influence-strategies-from-cialdini-s-7-principles -description: >- - Influence strategies from Cialdini's 7 principles. Use when the user needs a product - workflow for stakeholder management related to influence strategies from cialdini's 7 - principles. Trigger terms: influence, cialdini, stakeholder-management. ---- - - - -# Influence strategies from Cialdini's 7 principles - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `influence-strategies-from-cialdini-s-7-principles` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Influence strategies from Cialdini's 7 principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INFLUENCE_TARGET}} -- {{INFLUENCE_GOAL}} - - -GOAL -Produce a high-quality deliverable for: Influence strategies from Cialdini's 7 principles. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate influence ideas tailored to `{{INFLUENCE_TARGET}}` and `{{INFLUENCE_GOAL}}`. -- Provide at least one specific, actionable, ethical idea for each Cialdini principle: -- Reciprocity -- Liking -- Unity -- Authority -- Social Proof -- Consistency -- Scarcity -- For each idea, include a clear strategy and rationale tied to the target context and goal. -- Use professional, non-manipulative tactics that create value for both sides. - -FORMAT -Return exactly this structure: - - - -Name of the principle -Detailed description of the strategy or tactic -Explanation of why this idea would be effective for the given target and goal - -(Repeat this structure for each of the seven principles) - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Not all seven principles are covered, or principles are duplicated while another is missing. -- Strategies are generic, unethical/manipulative, or not tied to the target and goal. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/innovation-decision-making-heuristics/SKILL.md b/.claude/skills/innovation-decision-making-heuristics/SKILL.md deleted file mode 100644 index d62f1950..00000000 --- a/.claude/skills/innovation-decision-making-heuristics/SKILL.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -name: innovation-decision-making-heuristics -description: >- - Design tailored decision-making heuristics for uncertain innovation work. Use when the user - needs simple decision rules for product bets, discovery, investment, pivot, prioritization, - or opportunity selection in noisy and changing contexts. ---- - - - -# Innovation Decision Making Heuristics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovation-decision-making-heuristics` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop - -Use this skill when a team needs a practical decision rule, not a one-off recommendation. -The output should help the team decide repeatedly under uncertainty while avoiding arbitrary -or off-the-shelf rules. - -## Decision-Making Principles - -- Heuristics are useful shortcuts when the environment is noisy, dynamic, uncertain, or - time-sensitive and more information does not necessarily clarify direction. -- Heuristics fail when applied blindly, when nuance matters, or when the environment is stable - enough for more complete analysis. -- Effective heuristics should come from the user's real business challenge, constraints, - evidence, and observed feedback. -- A good heuristic makes tradeoffs explicit: speed versus accuracy, exploration versus focus, - safety versus moonshot, and learning versus commitment. -- Heuristics must be reviewed and refined through practical experience. - -## Workflow - -1. Identify the recurring decision type and the context in which it appears. -2. Classify the environment: noisy/dynamic/uncertain, stable, time-sensitive, multi-factor, - politically loaded, or high-stakes irreversible. -3. Define what the heuristic should optimize: learning, speed, risk control, focus, upside, - user value, revenue, retention, or strategic fit. -4. Identify where naive heuristics could fail. -5. Create 3-5 tailored decision rules with explicit triggers and exceptions. -6. Add a feedback loop so the rule can improve after use. - -## Output Contract - -Return: - -```markdown -# Innovation Decision Making Heuristics - -## 1. Recurring Decision -Decision type: -Who decides: -Frequency: -Time pressure: -Stakes: - -## 2. Decision Environment -Context: -Noise / uncertainty: -Information quality: -Reversibility: -Stable analysis possible: - -## 3. What The Rules Should Optimize -Primary objective: -Secondary objective: -Tradeoff to accept: -Tradeoff to avoid: - -## 4. Heuristic Failure Risks -Where shortcuts help: -Where shortcuts fail: -Bias risks: -Escalation or sunk-cost risk: - -## 5. Tailored Decision Rules -Rule 1: -Use when: -Exception: -Evidence needed: - -Rule 2: -Use when: -Exception: -Evidence needed: - -Rule 3: -Use when: -Exception: -Evidence needed: - -## 6. Feedback And Refinement -Signal to track: -Review cadence: -Who updates the rule: -When to retire the rule: -``` - -## Failure Modes - -- Provides generic principles instead of concrete decision rules. -- Creates rules that ignore the user's actual uncertainty, constraints, and feedback loops. -- Treats heuristics as always good or always bad rather than context-dependent. -- Omits exceptions and review mechanisms. diff --git a/.claude/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md b/.claude/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md deleted file mode 100644 index 37bbe578..00000000 --- a/.claude/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: innovative-idea-generation-from-project-parameters-and -description: >- - Innovative idea generation from project parameters and constraints. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, - product-management, osborn-checklist. ---- - - - -# Innovative idea generation from project parameters and constraints - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-project-parameters-and` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from project parameters and constraints**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_TYPE}} -- {{GOALS}} -- {{BUDGET}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from project parameters and constraints". -Success metric: -- Produces concrete, non-generic ideas that fit project type, goals, and budget. -- Uses structured creativity analysis (including Osborn checklist) to move beyond obvious solutions. -- Final ideas are immediately actionable with clear execution steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_TYPE}}`, `{{GOALS}}`, and `{{BUDGET}}`; if details are missing, state assumptions explicitly. -- Provide exactly 5 banal ideas to avoid and explain why each is weak. -- Define problem context including timeframe, target audience, and situation. -- Break down problem into objective, constraints, measurable success criteria, challenges, and deeper considerations. -- Analyze each chunk with explicit link to goals and budget feasibility. -- Include both creator and consumer perspectives. -- Apply Osborn checklist categories with project-relevant outputs: - - other uses, adaptations, modifications, magnification, minification, substitutions, rearrangements, reversals, combinations. -- Final ideas must be actionable for an individual, feasible under budget, and include step-by-step instructions plus application context. - -FORMAT -Return exactly this structure: - - - -1. [Banal idea] - [Why to avoid] -2. [Banal idea] - [Why to avoid] -3. [Banal idea] - [Why to avoid] -4. [Banal idea] - [Why to avoid] -5. [Banal idea] - [Why to avoid] - - - -[Clearly define the problem or situation] - - - -[Break down the problem into key aspects] - - - -[Provide in-depth analysis of each problem chunk] - - - -[Describe creator and consumer perspectives] - - - -- Other uses: [Ideas] -- Adaptations: [Ideas] -- Modifications: [Ideas] -- Magnification: [Ideas] -- Minification: [Ideas] -- Substitutions: [Ideas] -- Rearrangements: [Ideas] -- Reversals: [Ideas] -- Combinations: [Ideas] - - - -1. [Idea title] - - Specific guidance: [What to do] - - Steps: [Step-by-step] - - Where/how to apply: [Context/channel/tool] - - Budget fit: [How it stays within budget] -[Repeat for additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `banal_ideas` does not contain exactly 5 items. -- One or more Osborn checklist categories are missing. -- Final ideas are not actionable step-by-step or are not aligned to budget/goals. -- Output is generic or repeats clichรฉ ideas without meaningful differentiation. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md b/.claude/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 9f67111a..00000000 --- a/.claude/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -name: innovative-idea-generation-from-structured-brainstorming -description: >- - Innovative idea generation from structured brainstorming techniques. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, - creativity, product-discovery, problem-solving. ---- - - - -# Innovative idea generation from structured brainstorming techniques - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from structured brainstorming techniques**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from structured brainstorming techniques". -Success metric: -- Produces a structured ideation session using free association, mind mapping, SCAMPER, and bias checks. -- Generates non-obvious, high-potential ideas grounded in the topic. -- Outputs clear top ideas with rationale and a concise synthesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run a complete structured ideation flow: - - free association (4-6 rounds), - - mind map (3-4 levels), - - SCAMPER exploration (2-3 rounds across shortlisted branches), - - bias check, - - top-idea selection and rationale. -- Avoid clichรฉd or overhyped ideas; prioritize specificity and novelty. -- Ensure top ideas are distinct from one another and clearly connected to generated branches. -- Keep outputs practical enough to be explored/prototyped next. - -FORMAT -Return exactly this structure: - - - -[4-6 rounds of free associations tied to `{{TOPIC}}`] - - - -[Mind map with 3-4 branching levels derived from free associations] - - - -1. [Branch] -2. [Branch] -3. [Branch] - - - -[2-3 rounds applying SCAMPER prompts to shortlisted branches] - - - -- Anchoring check: [Findings/adjustment] -- Status quo check: [Findings/adjustment] -- Groupthink check: [Findings/adjustment] - - - -1. [Idea 1] -2. [Idea 2] -3. [Idea 3] - - - -1. [Why idea 1 is powerful and non-obvious] -2. [Why idea 2 is powerful and non-obvious] -3. [Why idea 3 is powerful and non-obvious] - - - - -1. [Idea 1]: [Rationale] -2. [Idea 2]: [Rationale] -3. [Idea 3]: [Rationale] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `freeassociation` has fewer than 4 rounds or more than 6 rounds. -- `mindmap` does not show 3-4 levels of branching. -- `scamper` does not include at least 2 rounds. -- `top_ideas` does not contain exactly 3 distinct ideas. -- Rationales are generic and do not explain non-obvious value. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md b/.claude/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 5f02fe73..00000000 --- a/.claude/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -name: innovative-product-ideas-from-structured-brainstorming -description: >- - Innovative product ideas from structured brainstorming. Use when the user needs a product - workflow for ideation & creativity related to innovative product ideas from structured - brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, - product-management. ---- - - - -# Innovative product ideas from structured brainstorming - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-product-ideas-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative product ideas from structured brainstorming**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative product ideas from structured brainstorming". -Success metric: -- Produces a complete structured brainstorming session from divergence to convergence. -- Generates non-obvious product ideas grounded in the topic and validated via bias checks. -- Returns exactly 3 top ideas with clear innovation rationale in abstract terms. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run all stages: free association, mind map, SCAMPER expansion, bias check, top-idea selection, summary. -- Avoid banal, overhyped, or clichรฉd outputs. -- Top ideas must be described abstractly; do not use specific tech buzzwords such as `AI`, `blockchain`, or `VR`. -- Ensure ideas are distinct and traceable to earlier brainstorming artifacts. - -FORMAT -Return exactly this structure: - - - - -1. [Word or phrase] -2. [Word or phrase] -... -[Total 8-10 items] - - - -[Topic] -- [Main branch 1] - - [Sub-branch 1a] - - [Sub-branch 1b] -- [Main branch 2] - - [Sub-branch 2a] - - [Sub-branch 2b] -- [Main branch 3] - - [Sub-branch 3a] - - [Sub-branch 3b] -[At least 3 main branches; each with 2-3 sub-branches] - - - -- Branch: [Name] - - Technique 1: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] - - Technique 2: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] -[Repeat for 3 branches] - - - -- Bias: [Name] - - Evidence in ideas: [How it appears] - - Countermeasure: [Concrete action] -[At least 1 bias] - - - -1. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -2. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -3. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] - - - -[Brief recap of process and why final ideas are stronger after SCAMPER and bias checks] - - - - -FAILURE -- Root tag `` or any required sub-tag is missing, malformed, or incomplete. -- `free_association` has fewer than 8 or more than 10 items. -- `mind_map` has fewer than 3 main branches or insufficient sub-branches. -- `scamper` does not cover 3 branches with 2 techniques each. -- `top_ideas` does not contain exactly 3 ideas. -- Top ideas include banned specific-technology terms (`AI`, `blockchain`, `VR`). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/interactive-intake-for-ost-inputs/SKILL.md b/.claude/skills/interactive-intake-for-ost-inputs/SKILL.md deleted file mode 100644 index 595f7d63..00000000 --- a/.claude/skills/interactive-intake-for-ost-inputs/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: interactive-intake-for-ost-inputs -description: >- - Interactive intake for OST inputs. Use when the user needs a product workflow for user - research related to interactive intake for ost inputs. Trigger terms: user-research, ost, - continuous-discovery. ---- - - - -# Interactive intake for OST inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `interactive-intake-for-ost-inputs` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Interactive intake for OST inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Interactive intake for OST inputs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Act as an intake orchestrator for downstream OST inputs. -- Parse existing user-provided context first, then ask only missing critical questions. -- Collect and normalize exactly four variables: -- `{{business_outcome}}`: one concise, outcome-focused sentence (no solution wording). -- `{{journey_nodes_as_list}}`: JSON array of distinct journey moments (not features). -- `{{interview_transcripts_or_story_snippets}}`: markdown snippets with attribution and timestamps when available. -- `{{constraints_or_principles}}`: short markdown list/sentence or `None stated`. -- Apply quality guards: -- Reframe solution-flavored outcomes into measurable outcomes. -- Rephrase feature-like nodes into moments in time. -- Add minimal attribution labels when transcript context is sparse. -- Stop only when all four fields are present, clear, distinct, normalized, and confirmed. - -FORMAT -Return exactly this structure: - -{{business_outcome}}: [one concise, outcome-focused sentence] - -{{journey_nodes_as_list}}: ["[Moment 1]", "[Moment 2]", "[Moment 3]"] - -{{interview_transcripts_or_story_snippets}}: -[markdown transcript/snippets with speaker labels and timestamps if available] - -{{constraints_or_principles}}: -[short markdown list or sentence; if none provided, write "None stated"] - -FAILURE -- Any of the four required variables is missing or malformed. -- `{{business_outcome}}` is solution-flavored or not measurable/outcome-oriented. -- `{{journey_nodes_as_list}}` is not valid JSON array syntax or contains features instead of moments. -- Interview material lacks usable attribution/context when source data allows it. -- Constraints field is omitted instead of explicitly set to `None stated`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/lean-canvas/SKILL.md b/.claude/skills/lean-canvas/SKILL.md deleted file mode 100644 index 4183465d..00000000 --- a/.claude/skills/lean-canvas/SKILL.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -name: lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- - - - -# Lean Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `lean-canvas` -- **Lifecycle**: Think -- **Category**: Business Model -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md b/.claude/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md deleted file mode 100644 index 79e8327c..00000000 --- a/.claude/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: limit-based-product-strategy-from-problem-to-execution-plan -description: >- - Limit-based product strategy from problem to execution plan. Use when the user needs a - product workflow for product strategy related to limit-based product strategy from problem - to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, - structured-thinking. ---- - - - -# Limit-based product strategy from problem to execution plan - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `limit-based-product-strategy-from-problem-to-execution-plan` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Limit-based product strategy from problem to execution plan**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Produce a high-quality deliverable for: Limit-based product strategy from problem to execution plan. -Success metric: -- Applies the full Limit-Based Product Thinking framework end-to-end. -- Produces concrete milestones, levers, assumptions, and a phased execution plan. -- Keeps outputs grounded in the provided problem statement. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM_STATEMENT}}`; if critical details are missing, state assumptions explicitly. -- Follow all 7 framework steps in order. -- Provide quantified convergence milestones at 10%, 25%, 50%, 75%, 90% with dates or triggers. -- Identify levers to accelerate convergence and explicitly name the top 1โ€“2 highest impact moves. -- List critical assumptions with validation methods. -- Provide a 3-phase plan (Foundation, Acceleration, Optimization) with timelines and resource guidance. - -FORMAT -Return exactly this structure: - - -1. Growth Variable: [Your identified variable] - -2. Limit State Description: - [Your vivid description of the fully mature state] - -3. Core Properties of the Limit: - [List of key features and interactions] - -4. Convergence Estimate: - [Growth curve and milestones] - -5. Acceleration Strategies: - [Prioritized list of levers to steepen the curve] - -6. Critical Assumptions: - [List of assumptions with validation methods] - -7. Product Vision and Execution: - Vision Statement: [One-sentence summary] - Roadmap: [Major milestones and timelines] - 3-Phase Plan: [Brief outline of each phase] - Resource Allocation: [Key recommendations] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Convergence milestones are missing required percentages or triggers/dates. -- Acceleration strategies lack prioritized top 1โ€“2 levers. -- Assumptions lack validation methods. -- 3-phase plan is missing or not sequenced. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/low-frequency-to-power-user-transition-strategy/SKILL.md b/.claude/skills/low-frequency-to-power-user-transition-strategy/SKILL.md deleted file mode 100644 index 22037568..00000000 --- a/.claude/skills/low-frequency-to-power-user-transition-strategy/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: low-frequency-to-power-user-transition-strategy -description: >- - Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow - for product strategy related to low-frequency-to-power-user transition strategy. Trigger - terms: product-strategy, engagement, activation, retention. ---- - - - -# Low-Frequency-to-Power-User Transition Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `low-frequency-to-power-user-transition-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Low-Frequency-to-Power-User Transition Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_DESCRIPTION}} -- {{CURRENT_USE_CASE}} -- {{TARGET_USE_CASE}} - - -GOAL -Produce a high-quality deliverable for: Low-Frequency-to-Power-User Transition Strategy. -Success metric: -- Produces a concrete transition plan from low-frequency to high-frequency usage. -- Aligns strategy to current and target use cases with explicit behavioral gaps. -- Includes metrics, timeline, and rollout/education plans grounded in the inputs. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_DESCRIPTION}}`, `{{CURRENT_USE_CASE}}`, and `{{TARGET_USE_CASE}}`; if information is missing, state assumptions explicitly. -- Identify the behavioral gap between current and target usage. -- Provide step-by-step transition plan, education/onboarding, and communication strategy. -- Include rollout plan, key metrics, and timeline for measurement. -- Keep recommendations specific and grounded in the provided context. - -FORMAT -Return exactly this structure: - - -1. Current Use Case Analysis: - [Provide a brief analysis of the current low-frequency use case] - -2. Target Use Case Analysis: - [Provide a brief analysis of the target high-frequency use case] - -3. User Behavior and Needs: - [Summarize key insights about user behavior and needs] - -4. Transition Strategy: - a. Feature Introduction Plan: - [Outline the step-by-step plan for introducing new features] - b. User Education and Onboarding: - [Describe the approach for educating users about the new use case] - c. Communication Strategy: - [Outline the key messages and channels for communicating the benefits] - d. Gradual Rollout Plan: - [Describe the approach for gradually introducing new functionality] - -5. Implementation and Measurement: - a. Key Metrics: - [List the primary metrics to track for measuring success] - b. Timeline: - [Provide a high-level timeline for implementation and evaluation] - c. Feedback and Iteration: - [Describe the plan for collecting user feedback and making improvements] - -6. Potential Challenges and Mitigation Strategies: - [Identify potential obstacles and propose solutions] - -7. Conclusion: - [Summarize the key points of the transition strategy and its potential impact] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Behavioral gap or barriers are not explicitly identified. -- Metrics or timeline are missing. -- Strategies are generic or not tied to the given use cases. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/managerial-finance-dcf/SKILL.md b/.claude/skills/managerial-finance-dcf/SKILL.md deleted file mode 100644 index 0e13f58c..00000000 --- a/.claude/skills/managerial-finance-dcf/SKILL.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -name: managerial-finance-dcf -description: >- - Productize Finance engine for time value of money, DCF, NPV, IRR, payback, free cash flow, - terminal value, project valuation, mutually exclusive investments, and whether growth - creates or destroys value. ---- - - - -# Managerial Finance DCF - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `managerial-finance-dcf` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings - -## Purpose - -Core investment-decision skill for evaluating projects and cash-flow streams. -Use it when comparing investments, building free cash flow forecasts, calculating -NPV/IRR/payback, estimating terminal value, or judging whether growth creates value. - -## Core Formulas - -- `FV_t = C_0 * (1 + r)^t` -- `PV = C_t / (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(C_t / (1 + r)^t)` -- `NPV with TV = -I_0 + sum(FCF_t / (1 + r)^t) + TV_N / (1 + r)^N` -- `0 = -I_0 + sum(C_t / (1 + IRR)^t)` -- `Profitability Index = PV of Future Cash Flows / Initial Investment` -- `FCF = EBIT * (1 - T_c) + Depreciation - CapEx - Delta NWC` -- `NOPAT = EBIT * (1 - T_c)` -- `TV_N = FCF_{N+1} / (r - g)` with `r > g` -- `ROIC = NOPAT / Invested Capital` -- `Reinvestment Rate = (CapEx - Depreciation + Delta NWC) / NOPAT` -- `g = ROIC * Reinvestment Rate` - -## Decision Rules - -- Independent projects: accept if `NPV > 0`; reject if `NPV < 0`. -- Mutually exclusive projects: choose the highest NPV. -- IRR supports the decision, but warn when cash flows change sign more than once, - projects differ in scale or timing, or multiple/no real IRRs exist. -- Growth creates value only when `ROIC > WACC`; it destroys value when `ROIC < WACC`. - -## Required Functions - -Use `$finance-modeling-kernel` functions for PV/FV, streams, NPV, IRR, payback, -discounted payback, annuities, perpetuities, free cash flow, terminal value, -ROIC, reinvestment rate, and sustainable growth. - -## Required Validation - -- Warn if comparing undiscounted cash flows across time. -- Warn if terminal growth exceeds long-run economic growth. -- Reject `g >= r` in growing perpetuity. -- Warn if IRR conflicts with NPV. -- Warn if payback is used as the final decision rule. -- Warn if sunk costs, financing cash flows, non-incremental overhead, cannibalization, - or opportunity cost are mishandled. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Make NPV the primary investment decision rule. diff --git a/.claude/skills/map-power-dynamics-before-meetings/SKILL.md b/.claude/skills/map-power-dynamics-before-meetings/SKILL.md deleted file mode 100644 index 106cf1e1..00000000 --- a/.claude/skills/map-power-dynamics-before-meetings/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: map-power-dynamics-before-meetings -description: >- - Map power dynamics before meetings. Use when the user needs a product workflow for - stakeholder management related to map power dynamics before meetings. Trigger terms: - stakeholders, power-dynamics, meetings, communication. ---- - - - -# Map power dynamics before meetings - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `map-power-dynamics-before-meetings` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Map power dynamics before meetings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DETAILS}} -- {{ATTENDEES_INFO}} - - -GOAL -Produce a high-quality deliverable for: "Map power dynamics before meetings". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{MEETING_DETAILS}}` and `{{ATTENDEES_INFO}}` to map meeting-specific power dynamics. -- Identify formal hierarchy, informal influence signals, alliances/conflicts, and each attendee's stake in outcomes. -- Rank attendees by influence in this meeting context. -- Identify decision-makers, influencers, power imbalances, and likely conflict points. -- Provide actionable strategies to navigate dynamics during the meeting. -- If information is insufficient for any claim, explicitly state the uncertainty. - -FORMAT -Return exactly this structure: - - - -[List attendees in order of influence, with brief notes on their power sources] - - - -[Bullet points of important observations about the power dynamics] - - - -[Bullet points of strategies to navigate the power dynamics effectively] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Influence ranking is not meeting-contextual or lacks power-source rationale. -- Recommendations are generic or not tied to identified dynamics/conflicts. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md b/.claude/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md deleted file mode 100644 index 05f3aa03..00000000 --- a/.claude/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: market-opportunities-from-jobs-to-be-done-market-canvas -description: >- - Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product - workflow for product strategy related to market opportunities from jobs-to-be-done market - canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, - product-strategy. ---- - - - -# Market opportunities from Jobs-to-be-Done market canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunities-from-jobs-to-be-done-market-canvas` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path - -Use this skill to run the Productize prompt contract for **Market opportunities from Jobs-to-be-Done market canvas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_OR_SERVICE}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Market opportunities from Jobs-to-be-Done market canvas. -Success metric: -- Guides the user through all 8 JTBD canvas steps with clear prompts. -- Keeps responses tied to provided `{{USER_INPUT}}` and the product context. -- Ends with a concise summary prompt that reflects the completed canvas. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_OR_SERVICE}}` and `{{USER_INPUT}}`; if context is missing, state assumptions explicitly. -- Ask for user input at each of the 8 JTBD canvas steps. -- Provide a brief explanation before each stepโ€™s prompt. -- Require the user to answer within the specified `` tags. -- End by requesting a `` that synthesizes the full canvas. -- Remind the user to use `{{USER_INPUT}}` when answering. - -FORMAT -Return exactly this structure: - - -[Prompt + explanation for Traditional Market Definition] - - - -[Prompt + explanation for Job Executor Determination] - - - -[Prompt + explanation for Abstracted Job Executor] - - - -[Prompt + explanation for Job Executor Documentation] - - - -[Prompt + explanation for Product Function Analysis] - - - -[Prompt + explanation for Complementary Product Analysis] - - - -[Prompt + explanation for Job Statement Abstraction] - - - -[Prompt + explanation for Final Job Documentation] - - - -[Prompt asking the user to summarize the completed canvas] - - -FAILURE -- Any required step tag in `FORMAT` is missing, malformed, or incomplete. -- Prompts do not request user responses within the correct `` tags. -- User is not reminded to use `{{USER_INPUT}}` for responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/market-opportunity/SKILL.md b/.claude/skills/market-opportunity/SKILL.md deleted file mode 100644 index 9772290f..00000000 --- a/.claude/skills/market-opportunity/SKILL.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -name: market-opportunity -description: >- - Identify, compare, and choose market opportunities for a venture, product, technology, or - innovation. Use when a founder, entrepreneur, product team, or innovator is choosing which - market to enter, picking a primary customer segment, evaluating whether a technology has - better use cases, deciding whether to pivot, comparing growth options, framing a venture for - investors, or asking variants of "which market should I target", "is this the right - opportunity", "where should I focus", "should I pivot", or "what else could this be used - for". Produces filled-in opportunity canvases for the Market Opportunity Set, Attractiveness - Map, Focus Portfolio Map, and Focus Strategy. Default to this skill when the question is - where to play rather than how to play. ---- - - - -# Market Opportunity - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunity` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market Opportunity venture brief with target segment, wedge, assumptions, and validation path - -Create the complete four-part market opportunity artifact set for choosing where a -venture, technology, product, or innovation should play. - -Use neutral terms such as `canvas`, `opportunity artifact`, `strategy surface`, or the -artifact names below. - -## Argument Hint - -`` - -## Usage - -```text -/market-opportunity $ARGUMENTS -``` - -## Required Artifacts - -For any complete request, create all four artifacts unless the user explicitly asks for -only one: - -1. **Opportunity Overview Canvas**: the three-part overview with opportunity set, - attractiveness map, and focus portfolio map. -2. **Opportunity Set Builder**: abilities -> applications -> customers -> market - opportunities. -3. **Attractiveness Evaluator**: potential and challenge ratings for each market - opportunity. -4. **Focus Portfolio Planner**: primary market opportunity, backup options, growth - options, and pursue/keep/store decisions. - -Load `references/canonical-canvases.md` before creating blank templates, filled -templates, printable layouts, or tables. It defines the exact fields and structure. - -Load `references/rating-and-decision-rules.md` before rating opportunities, -classifying map zones, or recommending primary, backup, and growth options. - -Load `references/output-formats.md` when the user asks for Markdown, HTML, PDF, -slides, visual canvases, or printable templates. - -## Workflow - -### 1. Establish the Input Mode - -Determine whether the user wants: - -- **Blank canvas set**: empty structured artifacts for a team to fill in. -- **Filled canvas set**: completed artifacts from a venture/product/technology idea. -- **Opportunity review**: critique or improve an existing opportunity set. -- **Strategy decision**: choose the primary opportunity and portfolio options. -- **Printable artifact**: create visual HTML/PDF/slide-ready canvases. - -If context is missing, ask only for the smallest useful missing piece: - -- The venture, product, technology, or core ability. -- Candidate applications. -- Candidate customer groups. -- Existing evidence for demand, market size, economics, implementation, timing, and risks. - -### 2. Generate the Market Opportunity Set - -Identify the venture's core abilities or technological elements first. Describe them -independent of the envisioned product. - -Then generate combinations: - -```text -market opportunity = application + customer segment -``` - -Segment customers precisely. Avoid broad labels like "enterprises" or "consumers" -unless the user has no better information. - -### 3. Evaluate Attractiveness - -For each market opportunity, rate: - -- **Potential** - - Compelling reason to buy. - - Market volume. - - Economic viability. -- **Challenge** - - Implementation obstacles. - - Time to revenue. - - External risks. - -Use the four-level rating scale: - -```text -Low / Mid / High / Super High -``` - -Then place each opportunity on the attractiveness map: - -- **Gold Mine** -- **Quick Win** -- **Moon Shot** -- **Questionable** - -### 4. Design the Focus Portfolio - -Choose one **Primary Market Opportunity** based on attractiveness and strategic fit. - -For other attractive opportunities, assess relatedness to the primary opportunity: - -- **Product relatedness**: shared technological competences, required resources, - and necessary networks. -- **Market relatedness**: shared customer values and benefits, sales channels, and - word-of-mouth paths. - -Classify each option: - -- **Growth Option**: attractive and useful for creating additional value. -- **Backup Option**: attractive and does not share major risks with the primary path. -- **Storage**: documented but not worth active preservation now. - -Make one of three action decisions for each option: - -- Pursue now. -- Keep open. -- Place in storage. - -The final strategy must keep at least one credible backup option and one credible -growth option open unless the available evidence makes that impossible. If impossible, -say what evidence or opportunity generation is missing. - -### 5. Tie Strategy to Execution - -For completed strategy outputs, include implications for: - -- Product and technology modularity. -- IP and defensibility. -- Hiring and capability development. -- Stakeholder and investor alignment. -- Brand and market communication. -- Experiments, assumptions, and learning loops. -- Business Model Canvas, Value Proposition Canvas, and Lean Startup integration when - the user asks for execution planning. - -## Output Rules - -- Preserve the canonical field names and rating scales from the reference files. -- Do not collapse the framework into SWOT, generic market sizing, or a feature - prioritization matrix. -- Be explicit about assumptions and evidence gaps. -- Use tables for editable outputs. -- For visual outputs, use the same four-artifact structure and neutral artifact titles. -- Do not copy long passages from source PDFs. Use the exact operational labels and - schemas, with original wording for explanations and recommendations. diff --git a/.claude/skills/market-opportunity/references/canonical-canvases.md b/.claude/skills/market-opportunity/references/canonical-canvases.md deleted file mode 100644 index a3c436db..00000000 --- a/.claude/skills/market-opportunity/references/canonical-canvases.md +++ /dev/null @@ -1,234 +0,0 @@ -# Canonical Market Opportunity Canvases - -Use these four canvases as the canonical output surfaces. Use neutral artifact names in -user-facing output. - -## 1. Opportunity Overview Canvas - -Purpose: show the entire flow from opportunity generation to attractiveness placement -to focus portfolio decision. - -Required fields: - -- Name. -- Date. -- Title: `Market Opportunity Overview`. -- Market opportunity definition: `application + customer`. -- Left panel: **Market Opportunity Set**. -- Middle panel: **Attractiveness Map**. -- Right panel: **Focus Portfolio Map**. - -### Market Opportunity Set Panel - -Contains market opportunity cards generated from: - -```text -application + customer = market opportunity -``` - -Each card should have: - -| Field | Description | -|---|---| -| ID | Short stable label such as MO-1, MO-2, MO-3 | -| Application | What the core ability enables | -| Customer segment | Who needs that application | -| Market opportunity | Combined application + customer | - -### Attractiveness Map Panel - -Axes: - -| Axis | Direction | Rating Levels | -|---|---|---| -| Potential | vertical | Low, Mid, High, Super High | -| Challenge | horizontal | Low, Mid, High, Super High | - -Zones: - -| Zone | Meaning | -|---|---| -| Gold Mine | High potential with relatively low challenge | -| Quick Win | Lower potential with relatively low challenge | -| Moon Shot | High potential with high challenge | -| Questionable | Lower potential with high challenge | - -### Focus Portfolio Map Panel - -Nested decision areas: - -| Area | Meaning | -|---|---| -| Pursue now | Active focus or active parallel pursuit | -| Keep open | Preserve option value without fully committing | -| Place in storage | Document but do not actively preserve now | - -Cards placed here must identify whether they are primary, backup, growth, or storage -options. - -## 2. Opportunity Set Builder - -Purpose: generate market opportunities by combining core abilities, applications, and -customer segments. - -Required fields: - -- Name. -- Date. -- Title: `Generate Your Market Opportunity Set`. -- Core abilities or technological elements. -- Applications. -- Customers. -- Market opportunities. - -### Core Abilities Table - -List the venture's core abilities or technological elements. Characterize each by -function and properties, independent from the envisioned product. - -| Ability ID | Core Ability or Technological Element | Function | Key Properties | Evidence / Notes | -|---|---|---|---|---| -| A1 | | | | | -| A2 | | | | | -| A3 | | | | | -| A4 | | | | | - -### Market Opportunity Generation Table - -Use each row to combine an application with a customer segment. - -| Opportunity ID | Ability ID(s) | Application | Customer Segment | Finer Customer Segmentation | Market Opportunity | -|---|---|---|---|---|---| -| MO-1 | | | | | | -| MO-2 | | | | | | -| MO-3 | | | | | | - -Generation prompts: - -- Which applications can the core abilities offer? -- Which customers may need each application? -- Can the customer group be segmented more precisely? -- Which combinations should be evaluated next? - -## 3. Attractiveness Evaluator - -Purpose: evaluate each market opportunity by potential and challenge, then place it -on the attractiveness map. - -Required fields: - -- Name. -- Date. -- Title: `Evaluate Market Opportunity Attractiveness`. -- Market Opportunity. -- Potential. -- Challenge. -- Overall Potential. -- Overall Challenge. -- Attractiveness Map zone. - -Use this canvas once for every market opportunity being evaluated. - -### Potential Ratings - -| Potential Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Compelling Reason to Buy | Unmet need; effective solution; better than current solutions | Low / Mid / High / Super High | | -| Market Volume | Current market size; expected growth | Low / Mid / High / Super High | | -| Economic Viability | Margins (value vs. cost); customers' ability to pay; customer stickiness | Low / Mid / High / Super High | | - -### Challenge Ratings - -| Challenge Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Implementation Obstacles | Product development difficulties; sales and distribution difficulties; funding challenges | Low / Mid / High / Super High | | -| Time to Revenue | Development time; time between product and market readiness; length of sales cycle | Low / Mid / High / Super High | | -| External Risks | Competitive threat; third-party dependencies; barriers to adoption | Low / Mid / High / Super High | | - -### Overall Placement - -| Market Opportunity | Overall Potential | Overall Challenge | Map Zone | Rationale | -|---|---|---|---|---| -| | Low / Mid / High / Super High | Low / Mid / High / Super High | Gold Mine / Quick Win / Moon Shot / Questionable | | - -## 4. Focus Portfolio Planner - -Purpose: design the focus strategy around one primary market opportunity while -preserving backup and growth options. - -Required fields: - -- Name. -- Date. -- Title: `Design Your Focus Strategy`. -- Primary Market Opportunity. -- Other attractive market opportunities. -- Product relatedness. -- Market relatedness. -- Suitable as backup option. -- Suitable as growth option. -- Action decision: pursue now, keep open, or place in storage. - -### Step I: Choose Primary Market Opportunity - -Choose the primary market opportunity based on the attractiveness map. - -| Primary Market Opportunity | Attractiveness Map Position | Why This Is Primary | Main Evidence | Main Risks | -|---|---|---|---|---| -| | | | | | - -### Step II: Examine Other Attractive Opportunities - -For each other attractive market opportunity, compare it with the primary opportunity. - -| Option ID | Market Opportunity | Product Relatedness | Product Relatedness Rationale | Market Relatedness | Market Relatedness Rationale | Risk Overlap With Primary | -|---|---|---|---|---|---|---| -| MO-2 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-3 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-4 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | - -Product relatedness asks how much the products share: - -- Technological competences. -- Required resources. -- Necessary networks. - -Market relatedness asks how much the customers share: - -- Values and benefits. -- Sales channels. -- Word-of-mouth paths. - -### Step III: Classify and Decide - -Use this table to mark whether each option is suitable as backup, growth, both, or -neither, then decide what to do with it. - -| Option ID | Market Opportunity | Backup Option? | Growth Option? | Action | Rationale | -|---|---|---|---|---|---| -| MO-2 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-3 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-4 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | - -Definitions: - -- **Backup Option**: an attractive market opportunity that does not share major risks - with the primary market opportunity and can support a change in direction. -- **Growth Option**: an attractive market opportunity that can create additional value - if the primary opportunity succeeds. - -Strategy rule: - -- Keep at least one Backup Option open. -- Keep at least one Growth Option open. -- Decide whether any option is worth pursuing now. -- Place the rest in storage. - -### Final Focus Strategy Summary - -| Category | Market Opportunity | Decision | Why | -|---|---|---|---| -| Primary | | Pursue now | | -| Backup | | Keep open / Pursue now | | -| Growth | | Keep open / Pursue now | | -| Storage | | Place in storage | | diff --git a/.claude/skills/market-opportunity/references/output-formats.md b/.claude/skills/market-opportunity/references/output-formats.md deleted file mode 100644 index ee145a61..00000000 --- a/.claude/skills/market-opportunity/references/output-formats.md +++ /dev/null @@ -1,143 +0,0 @@ -# Output Formats - -Use the same canonical four-artifact structure in every format. Use neutral artifact -names in titles and headings. - -## Markdown Blank Canvas Set - -Use when the user wants editable text tables. - -Required sections: - -```markdown -# Market Opportunity - -## 1. Opportunity Overview Canvas -[overview tables] - -## 2. Opportunity Set Builder -[blank abilities and opportunity generation tables] - -## 3. Attractiveness Evaluator -[one blank evaluator per opportunity, or reusable blank evaluator] - -## 4. Focus Portfolio Planner -[blank primary, relatedness, backup/growth, and action decision tables] -``` - -## Markdown Filled Canvas Set - -Use when the user provides a venture, technology, product, or opportunity set. - -Required sections: - -```markdown -# Market Opportunity: [Venture/Product] - -## 1. Opportunity Overview Canvas -- Market opportunity cards. -- Attractiveness placements. -- Focus portfolio decisions. - -## 2. Opportunity Set Builder -- Core abilities. -- Applications. -- Customer segments. -- Generated market opportunities. - -## 3. Attractiveness Evaluator -- One evaluation table per selected market opportunity. -- Overall potential, overall challenge, and map zone. - -## 4. Focus Portfolio Planner -- Primary market opportunity. -- Option comparison by product and market relatedness. -- Backup/growth classification. -- Pursue now / keep open / place in storage decisions. - -## Strategy Implications -- Product/technology modularity. -- IP and defensibility. -- Hiring/capability needs. -- Stakeholder and investor alignment. -- Brand and communication implications. -- Experiments and next evidence to collect. -``` - -## Visual or Printable Canvas - -Use when the user asks for printable templates, visual canvases, an HTML file, a PDF, -or a slide-ready output. - -Requirements: - -- Produce four separate pages or sections. -- Preserve the same layout logic: - - Overview: three panels side by side. - - Opportunity Set Builder: abilities at top; applications and customers below. - - Attractiveness Evaluator: potential on left, challenge on right, overall ratings at - the bottom. - - Focus Portfolio Planner: primary opportunity at top, option columns below, relatedness - rows, backup/growth rows, action rows at bottom. -- Use neutral artifact titles. -- Include `Name` and `Date` fields when producing a printable artifact. -- Include editable blank spaces or filled content depending on the requested mode. - -Recommended visual names: - -| Original Function | Use This Title | -|---|---| -| Full opportunity overview | Market Opportunity Overview | -| Generate opportunity set | Opportunity Set Builder | -| Evaluate attractiveness | Market Opportunity Attractiveness | -| Design focus strategy | Focus Strategy Planner | - -## Compact Decision Memo - -Use when the user wants a concise strategic answer rather than the full canvas set. - -Required sections: - -```markdown -## Recommendation -[Primary market opportunity and why] - -## Opportunity Portfolio -| Category | Opportunity | Decision | Why | - -## Key Ratings -| Opportunity | Potential | Challenge | Zone | - -## Risks and Open Assumptions -[Most important evidence gaps] - -## Next Tests -[Lean experiments or research needed] -``` - -## Spreadsheet-Friendly Format - -Use when the user wants to paste into Sheets/Excel. - -Create four CSV-style tables: - -1. `opportunity_set` -2. `attractiveness_ratings` -3. `map_placements` -4. `focus_portfolio` - -Minimum columns: - -```text -opportunity_set: -opportunity_id,ability_ids,application,customer_segment,finer_segment,market_opportunity - -attractiveness_ratings: -opportunity_id,potential_compelling_reason,potential_market_volume,potential_economic_viability,overall_potential,challenge_implementation,challenge_time_to_revenue,challenge_external_risks,overall_challenge,evidence_notes - -map_placements: -opportunity_id,overall_potential,overall_challenge,map_zone - -focus_portfolio: -opportunity_id,role,product_relatedness,market_relatedness,risk_overlap,backup_option,growth_option,action,rationale -``` diff --git a/.claude/skills/market-opportunity/references/rating-and-decision-rules.md b/.claude/skills/market-opportunity/references/rating-and-decision-rules.md deleted file mode 100644 index fdfe3093..00000000 --- a/.claude/skills/market-opportunity/references/rating-and-decision-rules.md +++ /dev/null @@ -1,250 +0,0 @@ -# Rating and Decision Rules - -Use these rules to keep opportunity ratings consistent. - -## Rating Scale - -Use only these four levels: - -```text -Low / Mid / High / Super High -``` - -For challenge dimensions, higher means more difficult, slower, riskier, or more -resource-intensive. Low challenge is good. - -## Potential Ratings - -### Compelling Reason to Buy - -Rate based on: - -- Strength of unmet need. -- Whether the solution effectively addresses the need. -- Whether it is better than current alternatives. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak pain, unclear need, or little advantage over alternatives | -| Mid | Recognizable need but limited urgency or differentiation | -| High | Clear need, strong solution fit, meaningful advantage | -| Super High | Urgent need, strong willingness to switch or buy, clear superiority | - -### Market Volume - -Rate based on: - -- Current market size. -- Expected growth. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Small or shrinking reachable market | -| Mid | Meaningful niche or uncertain growth | -| High | Large reachable market or strong growth | -| Super High | Very large market with strong growth and credible reach | - -### Economic Viability - -Rate based on: - -- Margins: value created versus cost to deliver. -- Customers' ability to pay. -- Customer stickiness. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak margins, low willingness or ability to pay, low retention potential | -| Mid | Economics may work but are not yet proven | -| High | Attractive value/cost relationship and credible willingness to pay | -| Super High | Strong margins, high willingness to pay, strong retention or lock-in | - -## Challenge Ratings - -### Implementation Obstacles - -Rate based on: - -- Product development difficulties. -- Sales and distribution difficulties. -- Funding challenges. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Straightforward product, go-to-market, and funding path | -| Mid | Some execution difficulty, but manageable | -| High | Significant product, distribution, or funding obstacles | -| Super High | Very difficult execution path or major resource gap | - -### Time to Revenue - -Rate based on: - -- Development time. -- Gap between product readiness and market readiness. -- Length of sales cycle. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Revenue can plausibly arrive quickly | -| Mid | Moderate path to revenue | -| High | Long development, readiness, or sales cycle | -| Super High | Very long or uncertain time to revenue | - -### External Risks - -Rate based on: - -- Competitive threat. -- Third-party dependencies. -- Barriers to adoption. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Limited external risk or manageable dependencies | -| Mid | Some competitive, dependency, or adoption risk | -| High | Serious external risks that could block progress | -| Super High | External risks may dominate the opportunity | - -## Overall Potential and Challenge - -Do not compute mechanically unless the user asks for numeric scoring. Use evidence and -judgment. - -Default aggregation: - -- Overall Potential should reflect the weakest critical potential dimension. A huge - market is not enough if there is no compelling reason to buy. -- Overall Challenge should reflect the hardest blocking challenge. A simple build is - not enough if revenue requires a multi-year sales cycle. - -If using numeric support: - -```text -Low = 1 -Mid = 2 -High = 3 -Super High = 4 -``` - -Use the rounded average as a starting point, then adjust for blockers and explain the -adjustment. - -## Attractiveness Map Zone Rules - -| Overall Potential | Overall Challenge | Zone | -|---|---|---| -| High or Super High | Low or Mid | Gold Mine | -| Low or Mid | Low or Mid | Quick Win | -| High or Super High | High or Super High | Moon Shot | -| Low or Mid | High or Super High | Questionable | - -Interpretation: - -- **Gold Mine**: strongest candidate for primary focus. -- **Quick Win**: potentially useful for learning, early traction, or stepping stones. -- **Moon Shot**: valuable but difficult; may require capital, patience, or unique assets. -- **Questionable**: weak candidate unless strategic reasons or new evidence change the view. - -## Primary Market Opportunity Rules - -Select the primary opportunity by weighing: - -- Attractiveness map zone. -- Strength of evidence. -- Founder/team fit. -- Ability to test assumptions. -- Strategic control and defensibility. -- Fit with resource constraints. - -Default preference: - -1. Gold Mine with strong evidence. -2. Gold Mine with evidence gaps but testable assumptions. -3. Quick Win if it creates learning, revenue, or capability for a larger path. -4. Moon Shot only if the upside is large enough and the team has unusual advantages. -5. Questionable only if the user explicitly has strategic reasons. - -## Backup Option Rules - -A backup option should be attractive and should not share major risks with the primary -opportunity. - -Good backup options often differ on: - -- Customer segment. -- Sales channel. -- Adoption barrier. -- Regulatory pathway. -- Revenue model. -- Critical dependency. - -Do not label an option as backup merely because it is related. If it fails for the same -reason the primary fails, it is not a useful backup. - -## Growth Option Rules - -A growth option should be attractive and should let the venture create additional value -after or alongside the primary opportunity. - -Good growth options often share: - -- Technology. -- Capabilities. -- Customer relationships. -- Distribution. -- Brand credibility. -- Data or network effects. - -High relatedness makes a growth option more plausible. Very low relatedness usually -means the opportunity is diversification, not a near-term growth option. - -## Action Decision Rules - -### Pursue Now - -Use when: - -- The option is primary, or -- The option is highly attractive, resources permit parallel pursuit, and pursuing it - does not dilute the primary focus. - -### Keep Open - -Use when: - -- The option has strategic value as backup or growth. -- The cost of preserving it is modest. -- It requires monitoring, lightweight experiments, modular design choices, IP claims, - partner conversations, or relationship maintenance. - -### Place in Storage - -Use when: - -- The option is not attractive enough now. -- The opportunity is too unrelated or costly to preserve. -- Evidence is too weak. -- It is worth remembering but not worth spending active effort on. - -## Evidence Discipline - -For each rating, distinguish: - -- Evidence: facts, interviews, data, observed behavior, signed interest, market numbers. -- Assumptions: plausible but unvalidated beliefs. -- Unknowns: missing information that could change the rating. - -When evidence is weak, phrase the output as a hypothesis and propose the next test. diff --git a/.claude/skills/market-orientation-audit/SKILL.md b/.claude/skills/market-orientation-audit/SKILL.md deleted file mode 100644 index 17642684..00000000 --- a/.claude/skills/market-orientation-audit/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: market-orientation-audit -description: >- - Audit whether an organization is truly market oriented using intelligence generation, - intelligence dissemination, and responsiveness. Use for customer-centricity, marketing - culture, organizational diagnosis, market sensing, and scorecard-based improvement plans. ---- - - - -# Market Orientation Audit - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-orientation-audit` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user wants to diagnose how well an organization senses markets, shares customer/competitor insight internally, and acts on that insight. - -Do not use it for brand health, campaign evaluation, or product-market fit unless the question is specifically about organizational market orientation. - -## Core Model - -Market orientation is an organization-wide culture and operating system for creating customer value. It has three dimensions: - -- **Intelligence generation**: how the organization detects customer, competitor, collaborator, technology, and regulatory changes. -- **Intelligence dissemination**: how quickly and effectively insight spreads across functions. -- **Responsiveness**: how fast and well the organization acts on market intelligence. - -## Scorecard - -Use a 1-5 scale: - -- 5 = Strongly agree -- 4 = Agree -- 3 = Neither agree nor disagree -- 2 = Disagree -- 1 = Strongly disagree - -Each dimension has 8 items. Dimension scoring: - -- 29-40 = High -- 20-28 = Moderate -- 8-19 = Low - -Total scoring: - -- 86-120 = High -- 60-85 = Moderate -- 24-59 = Low - -### Intelligence Generation - -1. We have interdepartmental meetings at least once a quarter to discuss market trends and developments. -2. We are quick to detect fundamental shifts in our industry, such as competition, technology, or regulation. -3. We periodically review the likely effect of environmental changes on customers. -4. We are fast to detect changes in customer product and service preferences. -5. People discuss customers' future needs with other functions or departments. -6. We do a lot of in-house market research. -7. We survey key customers at least once a year to assess product and service quality. -8. We meet key clients at least once a year to learn what products or services they will need in the future. - -### Intelligence Dissemination - -1. When something important happens to a major customer or market, the whole business knows quickly. -2. When one department learns something important about competitors, it quickly alerts other departments. -3. We would never ignore changes in customer product or service needs. -4. When customers want a product or service modification, involved teams make concerted efforts to respond. -5. We periodically review product or service development to ensure it aligns with key customer needs. -6. We have communication systems that speed dissemination of important customer-related information. -7. All functions and departments are responsive to each other's needs and requests. -8. When a customer complains or gives feedback, we quickly share it with anyone who can act on it. - -### Responsiveness - -1. It takes very little time to decide how to respond to competitor product or service changes. -2. We can implement new ideas, marketing plans, product redesigns, or service enhancements in a timely fashion. -3. Several functions periodically plan responses to changes in the business environment. -4. If a major competitor aggressively targeted a key customer, we would consider a response immediately. -5. We quickly act on customer complaints and feedback. -6. Customer-facing employees have latitude to solve customer problems without excessive red tape. -7. People here tend to talk more about opportunities than problems. -8. When we see a new opportunity to create customer value, we act quickly. - -## Workflow - -1. Collect scores from the user or run a facilitated self-assessment. -2. Compute dimension totals and total score. -3. Identify the weakest dimension and the lowest individual items. -4. Diagnose root causes across incentives, structure, tooling, decision rights, data access, rituals, and culture. -5. Translate findings into operating changes, not just research recommendations. -6. Define a 30/60/90-day improvement plan and measurement cadence. - -## Output - -Return: - -- **Score Summary**: dimension scores, total score, high/moderate/low rating. -- **Pattern Diagnosis**: what the scores imply about market sensing, sharing, and action. -- **Lowest Items**: the specific behaviors causing the largest gap. -- **Organizational Hurdles**: structure, incentives, data, rituals, authority, culture. -- **Improvement Plan**: 30/60/90-day actions. -- **Operating Metrics**: indicators to track improvement. - -## Quality Bar - -- Do not equate customer-facing friendliness with market orientation. -- Treat market orientation as cross-functional. -- Separate collecting insight from acting on insight. -- Recommend concrete operating changes, not generic "talk to customers more" advice. diff --git a/.claude/skills/market-requirements-from-strategic-market-inputs/SKILL.md b/.claude/skills/market-requirements-from-strategic-market-inputs/SKILL.md deleted file mode 100644 index 88fc1676..00000000 --- a/.claude/skills/market-requirements-from-strategic-market-inputs/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: market-requirements-from-strategic-market-inputs -description: >- - Market requirements from strategic market inputs. Use when the user needs a product workflow - for product strategy related to market requirements from strategic market inputs. Trigger - terms: product-management, market-research, strategy, MRD. ---- - - - -# Market requirements from strategic market inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-requirements-from-strategic-market-inputs` -- **Lifecycle**: Strategize -- **Category**: Discovery -- **Primary artifact**: Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Market requirements from strategic market inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MARKET_INDUSTRY}} -- {{PROBLEM_UNMET_NEED}} -- {{TARGET_USER_BUYER}} -- {{CURRENT_ALTERNATIVES}} -- {{COMPANY_ROLE_VISION_ADVANTAGE}} -- {{EXTERNAL_FACTORS}} -- {{OUTPUT_REQUEST}} - - -GOAL -Produce a high-quality deliverable for: Market requirements from strategic market inputs. -Success metric: -- Gathers required MRD inputs via a structured question flow. -- Produces decision-ready MRD sections only after the user confirms โ€œReady to draft.โ€ -- Keeps analysis concise, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; ask one question at a time until the user says **โ€œReady to draft.โ€** -- Do not draft any MRD section before the user explicitly says **โ€œReady to draft.โ€** -- After the user selects the output (Aโ€“D), produce that section only and pause for feedback. -- Use links for citations; state assumptions explicitly. -- No emojis. No JSON output. - -FORMAT -Return exactly this structure: - - -Letโ€™s co-create a Market Requirements Document. Iโ€™ll ask a few questions to gather context and then generate a draft. First up: What market or industry are you exploring? - - - -[Your single next question based on the most recent answer] - - -[When user says โ€œReady to draft,โ€ respond with exactly one of the requested MRD sections using the MRD Output Format headings.] - -FAILURE -- Output drafts MRD sections before user says โ€œReady to draft.โ€ -- More than one question is asked at a time. -- Output does not follow the selected section from Aโ€“D. -- Missing citations/assumptions where needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/market-sizing/SKILL.md b/.claude/skills/market-sizing/SKILL.md deleted file mode 100644 index d07b45e7..00000000 --- a/.claude/skills/market-sizing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, - market-entry upside, or investor-ready opportunity size. ---- - - - -# Market Sizing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-sizing` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.claude/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md b/.claude/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md deleted file mode 100644 index 1d0f8bda..00000000 --- a/.claude/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: mece-analysis-and-logical-tree-from-list-items -description: >- - MECE analysis and logical tree from list items. Use when the user needs a product workflow - for decision making related to mece analysis and logical tree from list items. Trigger - terms: pm, decision-making, mece, structured-thinking, frameworks. ---- - - - -# MECE analysis and logical tree from list items - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `mece-analysis-and-logical-tree-from-list-items` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **MECE analysis and logical tree from list items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{LIST_OF_ITEMS}} - - -GOAL -Evaluate `LIST_OF_ITEMS` for MECE quality and produce a logical tree that resolves overlaps/gaps. -Success metric: -- Clearly assesses mutual exclusivity and collective exhaustiveness. -- Identifies concrete overlaps and coverage gaps (if any). -- Produces a coherent tree structure reflecting corrected grouping logic. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Test pairwise overlap (mutual exclusivity). - 2. Test coverage gaps (collective exhaustiveness). - 3. Propose corrected structure and hierarchy. -- Keep conclusions grounded in the provided list; avoid unrelated frameworks unless necessary. -- If ambiguity exists in item definitions, state assumptions explicitly. -- Provide concise rationale, not hidden/internal chain-of-thought. - -FORMAT -Return exactly this structure: - - - -[State whether items are mutually exclusive, with specific overlap examples where relevant] - - -[State whether items are collectively exhaustive, with specific gap examples where relevant] - - -[Concise list of overlap issues and/or coverage gaps] - - - - -[MECE status: Fully MECE | Not MECE | Partially MECE] - -[Hierarchical tree showing corrected structure and item placement] - - - -FAILURE -- Required schema sections are missing or malformed. -- Mutual exclusivity or collective exhaustiveness assessment is absent. -- Logical tree is missing, unclear, or inconsistent with analysis findings. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/meeting-agendas-from-meeting-descriptions/SKILL.md b/.claude/skills/meeting-agendas-from-meeting-descriptions/SKILL.md deleted file mode 100644 index b89b0233..00000000 --- a/.claude/skills/meeting-agendas-from-meeting-descriptions/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: meeting-agendas-from-meeting-descriptions -description: >- - Meeting agendas from meeting descriptions. Use when the user needs a product workflow for - project management related to meeting agendas from meeting descriptions. Trigger terms: - meetings, facilitation, planning, productivity. ---- - - - -# Meeting agendas from meeting descriptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-agendas-from-meeting-descriptions` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Meeting agendas from meeting descriptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DESCRIPTION}} - - -GOAL -Produce a high-quality deliverable for: "Meeting agendas from meeting descriptions". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a meeting preparation output from `{{MEETING_DESCRIPTION}}` that includes: -- A clear purpose statement for the meeting. -- A structured agenda with allocated time per topic and key questions per topic. -- A practical process/flow for running the meeting to achieve the stated purpose. -- Internally reason from meeting goals, stakeholders, and constraints; return only the required final sections. - -FORMAT -Return exactly this structure: - - -[Clear and concise purpose statement] - - - -1. [Agenda Topic 1] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -2. [Agenda Topic 2] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -[Additional agenda topics] - - - -[Suggested process and flow for the meeting] - - -FAILURE -- Any required section (``, ``, ``) is missing or materially incomplete. -- Agenda items do not include both time allocation and key questions. -- Meeting flow/process is generic and not tied to the stated purpose. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md b/.claude/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md deleted file mode 100644 index 3656b570..00000000 --- a/.claude/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- - - - -# Meeting Outcome Planning and Stakeholder Alignment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-outcome-planning-and-stakeholder-alignment` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md b/.claude/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md deleted file mode 100644 index 5d07baa1..00000000 --- a/.claude/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: meeting-summaries-from-meeting-transcript-ideas-framework -description: >- - Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a - product workflow for presentation & communication related to meeting summaries from meeting - transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, - note-taking. ---- - - - -# Meeting summaries from meeting transcript (IDEAS framework) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-summaries-from-meeting-transcript-ideas-framework` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Meeting summaries from meeting transcript (IDEAS framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Meeting summaries from meeting transcript (IDEAS framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are tasked with summarizing a meeting using the IDEAS framework. This framework helps organize the key points of a meeting into five categories: Insights, Decisions, Engagements, Actions, and Summary. Here's the meeting transcript you need to analyze: - - -{{MEETING_TRANSCRIPT}} - - -Please carefully read and analyze the meeting transcript. Then, summarize the meeting using the IDEAS framework as follows: - -1. Insights: Identify and list the main insights or important realizations that emerged during the meeting. -2. Decisions: Note any decisions that were made during the meeting. -3. Engagements: List any tasks or responsibilities that were assigned to specific individuals or teams. -4. Actions: Highlight any immediate actions that need to be taken as a result of the meeting. -5. Summary: Provide a brief overall summary of the meeting's impact and significance. - -When writing your summary, please be concise and focused. Aim to capture the most important points rather than trying to include every detail. Use bullet points for each category to make the summary easy to read and understand. - -Present your summary using the following format, enclosed in XML tags: - -Remember to focus on the most significant and relevant information for each category. Your goal is to provide a clear, organized, and useful summary of the meeting using the IDEAS framework. - - -FORMAT -Return exactly this structure: - - - -โ€ข [List insights here] - - - -โ€ข [List decisions here] - - - -โ€ข [List engagements here] - - - -โ€ข [List actions here] - - - -[Write a brief overall summary here] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/message-framing-and-comms-plan-designer/SKILL.md b/.claude/skills/message-framing-and-comms-plan-designer/SKILL.md deleted file mode 100644 index 10e27875..00000000 --- a/.claude/skills/message-framing-and-comms-plan-designer/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: message-framing-and-comms-plan-designer -description: >- - Message Framing & Comms Plan Designer. Use when the user needs a product workflow for - stakeholder management related to message framing & comms plan designer. Trigger terms: - communication, executive-communication, messaging, stakeholder-management. ---- - - - -# Message Framing & Comms Plan Designer - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `message-framing-and-comms-plan-designer` -- **Lifecycle**: Design -- **Category**: Marketing -- **Primary artifact**: Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Message Framing & Comms Plan Designer**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Message Framing & Comms Plan Designer. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use provided facts, audience, goal, and writing sample to design a message framing and communication plan. -- Provide 2-3 viable framing options, each with a one-line rationale tied to credibility, logic, and audience emotion. -- Produce two concise drafts in the user's natural tone: -- `ICs` draft with context, changes, actions, and timeline (`<=180` words). -- `Execs` draft with BLUF, risks/asks, and decision needed (`<=120` words). -- Include a strong subject/headline and two Slack snippets (announcement + reminder). -- Provide a mini comms plan with channel sequence, owner, timing, emphasis, and CTA. -- Include a `What to Omit` noise-reduction list and exactly 3 success signals. - -FORMAT -Return exactly this structure: - -Frames & Rationale -- [Frame 1]: [one-line rationale] -- [Frame 2]: [one-line rationale] -- [Frame 3 if used]: [one-line rationale] - -Draft for ICs -Subject/Headline: [text] -[ICs draft <=180 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Draft for Execs -Subject/Headline: [text] -[Execs draft <=120 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Mini Comms Plan -| Step | Channel | Owner | Timing | Emphasis | CTA | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -What to Omit -- [item] - -Success Signals -1. [signal] -2. [signal] -3. [signal] - -FAILURE -- Any required section is missing or materially incomplete. -- ICs draft exceeds 180 words or Execs draft exceeds 120 words. -- Missing subject/headline or missing either Slack snippet type (announcement/reminder). -- Comms plan table is missing required columns or sequence logic. -- Success Signals are not exactly three measurable indicators. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.claude/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md b/.claude/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md deleted file mode 100644 index d742d045..00000000 --- a/.claude/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- - - - -# Metric drops diagnosis with rigorous stepwise decomposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- **Lifecycle**: Strategize -- **Category**: Analytics -- **Primary artifact**: Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/.claude/skills/metrics-review/SKILL.md b/.claude/skills/metrics-review/SKILL.md deleted file mode 100644 index 2f23b171..00000000 --- a/.claude/skills/metrics-review/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: metrics-review -description: >- - Review and analyze product metrics with trend analysis and actionable insights. Use when - running a weekly, monthly, or quarterly metrics review, investigating a spike or drop, - comparing against targets, or turning raw numbers into a scorecard with recommended actions. ---- - - - -# Metrics Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metrics-review` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Metric scorecard, trend diagnosis, and recommended action plan - -Review product metrics, identify trends, and surface action-oriented insights. - -## Argument Hint - -`
` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/.cursor/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md b/.cursor/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md deleted file mode 100644 index 58de7bfa..00000000 --- a/.cursor/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: productize-feature-impact-models-from-kpis-and-assumptions -description: >- - Feature impact models from KPIs and assumptions. Use when the user needs a product workflow - for business analysis related to feature impact models from kpis and assumptions. Trigger - terms: pm, business-analysis, financial-modeling, kpi-impact. ---- - - - -# Feature impact models from KPIs and assumptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-impact-models-from-kpis-and-assumptions` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Feature impact models from KPIs and assumptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_INFO}} -- {{KPIS_TO_ESTIMATE}} - - -GOAL -Produce a high-quality deliverable for: Feature impact models from KPIs and assumptions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Build a procedural task list that covers: - - key assumptions, - - baseline metric calculations, - - per-KPI impact estimation, - - sensitivity analysis. -- Execute the tasks and show calculations step by step using explicit formulas/equations. -- For each KPI, provide: - - point estimate, - - assumptions and calculations used, - - brief explanation of feature-to-KPI impact mechanism. -- If information is missing, state what is missing, add a reasonable assumption, label it clearly, and proceed. -- Prioritize transparent math and reasoning over spreadsheet-like verbosity. -- Keep conclusions focused on executive decision-making (investment impact, major drivers, key risks). - - -FORMAT -Return exactly this structure: - - - -[List the procedural tasks used to build the model] - - - -[Step-by-step calculations, formulas, assumptions, and point estimates for each KPI] - - - -[Feature overview, KPI estimate table/list, key assumptions, sensitivity-analysis takeaways, and executive conclusions] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md b/.cursor/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md deleted file mode 100644 index ba3f5a3b..00000000 --- a/.cursor/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- - - - -# Feature results analysis from draft to final report - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-results-analysis-from-draft-to-final-report` -- **Lifecycle**: Launch & Learn -- **Category**: Analytics -- **Primary artifact**: Feature results readout with iterate, rollback, kill, or scale recommendation - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-features-reframing-and-projects-shape-up/SKILL.md b/.cursor/skills/productize-features-reframing-and-projects-shape-up/SKILL.md deleted file mode 100644 index 0049fb31..00000000 --- a/.cursor/skills/productize-features-reframing-and-projects-shape-up/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: productize-features-reframing-and-projects-shape-up -description: >- - Features reframing and projects Shape Up. Use when the user needs a product workflow for - technical related to features reframing and projects shape up. Trigger terms: - product-strategy, shaping, scope-management, stakeholder-management, technical. ---- - - - -# Features reframing and projects Shape Up - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `features-reframing-and-projects-shape-up` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Features reframing and projects Shape Up**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_OR_PROJECT}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Features reframing and projects Shape Up. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reframe `{{FEATURE_OR_PROJECT}}` using Shape Up principles and provided `{{CONTEXT}}`. -- Provide a shaped work definition that is concrete enough for delivery but avoids build-phase implementation detail. -- Include: -- Appetite assessment (`1-2 weeks` or `6 weeks`) with rationale. -- Problem framing (problem-first, not solution-first). -- Boundary definition (in-scope / out-of-scope). -- Solution sketch at fat-marker level. -- Risks/rabbit holes and circuit-breakers. -- Explicit no-gos. -- Executive constraint language to secure scope commitment and prevent mid-cycle scope creep. -- Keep output focused on shaping quality, delivery constraints, and stakeholder alignment. - -FORMAT -Return exactly this structure: - -Shape Up Reframe - -Appetite Assessment -- Recommended appetite: [1-2 weeks or 6 weeks] -- Why this appetite: [rationale] - -Problem Framing -- Core problem: [problem statement] -- Why this matters now: [impact/context] -- Success condition: [what success looks like] - -Boundary Definition -- In scope: - - [item] -- Out of scope: - - [item] - -Solution Sketching (Fat Marker Level) -- Key approach: [high-level approach] -- Main interaction/surface 1: [conceptual behavior] -- Main interaction/surface 2: [conceptual behavior] - -Risks and Rabbit Holes -- [risk/rabbit hole] -- Circuit-breaker: [constraint or stop-rule] - -No-gos -- [explicit exclusion] - -Executive Constraints -- Commitment language: [specific wording to secure scope agreement] -- Change-control rule: [how new requests are handled mid-cycle] -- Escalation path: [who decides if scope must change] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Output drifts into build-phase implementation details instead of shaping-level decisions. -- Boundaries/no-gos are vague or do not constrain scope. -- Executive constraint handling is missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-finance-modeling-kernel/SKILL.md b/.cursor/skills/productize-finance-modeling-kernel/SKILL.md deleted file mode 100644 index 538d3739..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/SKILL.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: productize-finance-modeling-kernel -description: >- - Shared Productize Finance calculation and validation kernel for exact formulas, input - normalization, assumption checks, units, warnings, and acceptance-tested finance math used - by valuation, DCF, cost-of-capital, capital-structure, VC deal, and market-context skills. ---- - - - -# Finance Modeling Kernel - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `finance-modeling-kernel` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings - -## Purpose - -Shared calculation and validation library used by all Productize Finance skills. -Use this skill when a finance workflow needs exact formulas, normalized inputs, -assumption checks, error handling, units, or validation before making a recommendation. - -## Kernel Modules - -- `finance-modeling-kernel/time_value.py`: PV, FV, annuities, perpetuities, spot-rate streams. -- `finance-modeling-kernel/dcf.py`: NPV, IRR, payback, free cash flow, terminal value, ROIC, growth. -- `finance-modeling-kernel/returns.py`: realized returns, expected return, variance, volatility, covariance, correlation. -- `finance-modeling-kernel/risk.py`: portfolio variance, covariance, correlation, beta, regression beta. -- `finance-modeling-kernel/capm.py`: CAPM, unlevered beta, relevered beta. -- `finance-modeling-kernel/wacc.py`: WACC with market-value weights. -- `finance-modeling-kernel/apv.py`: tax shields and APV. -- `finance-modeling-kernel/valuation.py`: DCF valuation, terminal value, EV-to-equity bridge, multiples, sensitivities. -- `finance-modeling-kernel/capital_structure.py`: EV, equity value, leverage, MM, tax shields, APV. -- `finance-modeling-kernel/bond_math.py`: bond price, yield to maturity, current yield, credit spread. -- `finance-modeling-kernel/vc_method.py`: burn, runway, VC target multiple, pre/post-money, shares. -- `finance-modeling-kernel/cap_table.py`: fully diluted shares, ownership, dilution, cap table sum checks. -- `finance-modeling-kernel/convertible_notes.py`: note conversion amount, discount price, cap price, shares. -- `finance-modeling-kernel/safes.py`: SAFE conversion price, SAFE shares, post-money SAFE ownership. -- `finance-modeling-kernel/preferred_stock.py`: liquidation preference and preferred payoff waterfalls. -- `finance-modeling-kernel/option_pools.py`: investor-friendly and founder-friendly option pool math. -- `finance-modeling-kernel/market_context.py`: market cap, weights, listing changes, CAGR. -- `finance-modeling-kernel/validation.py`: shared validation errors and warning helpers. -- `finance-modeling-kernel/tests/`: acceptance tests for the minimum formula examples. - -## Finance Output Format - -All Productize Finance agents must return: - -1. **Inputs** -2. **Assumptions** -3. **Formula used** -4. **Calculation** -5. **Result** -6. **Interpretation** -7. **Warnings** - -## Global Guardrails - -1. Never compare cash flows at different dates without compounding or discounting. -2. Use market values, not book values, for valuation and WACC weights whenever possible. -3. Match discount rates to cash-flow risk. -4. Do not use a company WACC for a project with materially different risk. -5. Do not mix financing cash flows into operating free cash flow. -6. Use NPV as the primary investment decision rule. -7. Treat IRR, payback, and multiples as supporting tools, not final truth. -8. For VC deals, always state whether share counts are basic or fully diluted. -9. For option pools, always state whether the pool is investor-friendly or founder-friendly. -10. For convertible notes and SAFEs, always read the conversion definition before calculating. -11. For preferred stock, model the payoff waterfall, not only the ownership percentage. - -## Workflow - -1. Identify the finance problem and the cash-flow timing, units, currency, and risk basis. -2. Choose the exact module and function; do not invent ad hoc formulas when a kernel function exists. -3. Validate formula preconditions, especially `r > g`, positive denominators, share-count basis, and market-value weights. -4. Calculate transparently enough that the user can audit the math. -5. Return the standard Finance output format and warnings. - -## Acceptance Tests - -Run: - -```sh -python3 skills/finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py -``` - -The test suite covers DCF NPV, growing perpetuity, CAPM, WACC, VC target multiple, -post-money/pre-money, convertible note discount conversion, investor-friendly option -pool, and non-participating preferred payoff. diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py deleted file mode 100644 index 754f2374..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py +++ /dev/null @@ -1,10 +0,0 @@ -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py deleted file mode 100644 index bbbe83d7..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py +++ /dev/null @@ -1,36 +0,0 @@ -from validation import FinanceValidationError, require_positive - - -def bond_price(coupon, face_value, yield_to_maturity, periods): - if yield_to_maturity == 0: - return coupon * periods + face_value - return coupon * (1 - (1 + yield_to_maturity) ** (-periods)) / yield_to_maturity + face_value / (1 + yield_to_maturity) ** periods - - -def yield_to_maturity(price, coupon, face_value, periods, tolerance=1e-7, max_iterations=200): - require_positive("price", price) - low = -0.999999 - high = 1.0 - while bond_price(coupon, face_value, high, periods) > price and high < 1000: - high *= 2 - if high >= 1000: - raise FinanceValidationError("Yield to maturity could not be bracketed.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_price = bond_price(coupon, face_value, mid, periods) - if abs(mid_price - price) <= tolerance: - return mid - if mid_price > price: - low = mid - else: - high = mid - return (low + high) / 2 - - -def current_yield(annual_coupon, bond_price_value): - require_positive("bond_price", bond_price_value) - return annual_coupon / bond_price_value - - -def credit_spread(risky_yield, risk_free_yield): - return risky_yield - risk_free_yield diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py deleted file mode 100644 index 73d96466..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py +++ /dev/null @@ -1,19 +0,0 @@ -from validation import require_positive - - -def fully_diluted_shares(common=0, preferred_as_converted=0, options_issued=0, option_pool_unissued=0, warrants=0, convertibles=0): - return common + preferred_as_converted + options_issued + option_pool_unissued + warrants + convertibles - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares - - -def dilution(old_ownership_percentage, new_ownership_percentage): - require_positive("old_ownership_percentage", old_ownership_percentage) - return 1 - new_ownership_percentage / old_ownership_percentage - - -def cap_table_sums_to_100(ownership_percentages, tolerance=1e-6): - return abs(sum(ownership_percentages) - 1) <= tolerance diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py deleted file mode 100644 index e8e7565e..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py +++ /dev/null @@ -1,51 +0,0 @@ -from validation import require_positive - - -def enterprise_value(equity_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return equity_value + debt + preferred_stock + minority_interest - cash - nonoperating_assets - - -def equity_value_from_ev(enterprise_value_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def debt_to_equity(debt, equity): - require_positive("equity", equity) - return debt / equity - - -def debt_to_value(debt, equity): - require_positive("debt plus equity", debt + equity) - return debt / (debt + equity) - - -def degree_of_financial_leverage(ebit, interest): - require_positive("ebit minus interest", ebit - interest) - return ebit / (ebit - interest) - - -def wacc(equity, debt, cost_of_equity, cost_of_debt, tax_rate): - total = equity + debt - require_positive("debt plus equity", total) - return equity / total * cost_of_equity + debt / total * (1 - tax_rate) * cost_of_debt - - -def mm_value_no_taxes(unlevered_value): - return unlevered_value - - -def mm_cost_of_equity_no_taxes(unlevered_cost_of_capital, cost_of_debt, debt, equity): - require_positive("equity", equity) - return unlevered_cost_of_capital + debt / equity * (unlevered_cost_of_capital - cost_of_debt) - - -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py deleted file mode 100644 index 19a58da7..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py +++ /dev/null @@ -1,21 +0,0 @@ -from validation import require_positive - - -def capm_cost_of_equity(risk_free_rate, beta, market_risk_premium): - return risk_free_rate + beta * market_risk_premium - - -def unlever_beta(beta_l, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_l / (1 + (1 - tax_rate) * debt / equity) - - -def relever_beta(beta_u, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_u * (1 + (1 - tax_rate) * debt / equity) - - -def asset_beta_with_debt_beta(beta_equity, beta_debt, debt, equity, tax_rate=0): - require_positive("total capital", debt + equity) - tax_adjusted_debt = debt * (1 - tax_rate) - return (beta_equity * equity + beta_debt * tax_adjusted_debt) / (equity + tax_adjusted_debt) diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py deleted file mode 100644 index 9d05470a..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py +++ /dev/null @@ -1,27 +0,0 @@ -from validation import require_positive - - -def convertible_note_conversion_amount(principal, interest_rate, time, compounding_method="simple"): - if compounding_method == "simple": - return principal * (1 + interest_rate * time) - if compounding_method == "compound": - return principal * (1 + interest_rate) ** time - raise ValueError("compounding_method must be simple or compound.") - - -def convertible_note_discount_price(series_a_price, discount_rate): - return (1 - discount_rate) * series_a_price - - -def convertible_note_cap_price(valuation_cap, cap_share_count): - require_positive("cap_share_count", cap_share_count) - return valuation_cap / cap_share_count - - -def convertible_note_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def convertible_note_shares(conversion_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return conversion_amount / conversion_price diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py deleted file mode 100644 index 204cb98b..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py +++ /dev/null @@ -1,73 +0,0 @@ -from validation import FinanceValidationError, require_positive, require_rate_greater_than_growth - - -def npv(initial_investment, cash_flows, discount_rate): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def npv_with_terminal_value(initial_investment, fcfs, discount_rate, terminal_value): - return npv(initial_investment, fcfs, discount_rate) + terminal_value / (1 + discount_rate) ** len(fcfs) - - -def irr(cash_flows, tolerance=1e-7, max_iterations=200): - def value(rate): - return sum(cash_flow / (1 + rate) ** period for period, cash_flow in enumerate(cash_flows)) - - low = -0.999999 - high = 1.0 - low_value = value(low) - high_value = value(high) - while low_value * high_value > 0 and high < 1000: - high *= 2 - high_value = value(high) - if low_value * high_value > 0: - raise FinanceValidationError("IRR could not be bracketed; cash flows may have no real IRR or multiple IRRs.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_value = value(mid) - if abs(mid_value) <= tolerance: - return mid - if low_value * mid_value < 0: - high = mid - high_value = mid_value - else: - low = mid - low_value = mid_value - return (low + high) / 2 - - -def payback_period(cash_flows): - cumulative = 0 - for period, cash_flow in enumerate(cash_flows): - cumulative += cash_flow - if cumulative >= 0: - return period - return None - - -def discounted_payback_period(cash_flows, discount_rate): - discounted = [cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows)] - return payback_period(discounted) - - -def free_cash_flow(ebit, tax_rate, depreciation, capex, delta_nwc): - return ebit * (1 - tax_rate) + depreciation - capex - delta_nwc - - -def terminal_value_gordon(fcf_next, discount_rate, growth_rate): - require_rate_greater_than_growth(discount_rate, growth_rate, "discount_rate") - return fcf_next / (discount_rate - growth_rate) - - -def roic(nopat, invested_capital): - require_positive("invested_capital", invested_capital) - return nopat / invested_capital - - -def reinvestment_rate(capex, depreciation, delta_nwc, nopat): - require_positive("nopat", nopat) - return (capex - depreciation + delta_nwc) / nopat - - -def sustainable_growth(roic_value, reinvestment_rate_value): - return roic_value * reinvestment_rate_value diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py deleted file mode 100644 index 7596a040..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py +++ /dev/null @@ -1,34 +0,0 @@ -from validation import require_positive - - -def market_cap(price, shares_outstanding): - return price * shares_outstanding - - -def market_weight(company_market_cap, total_market_cap): - require_positive("total_market_cap", total_market_cap) - return company_market_cap / total_market_cap - - -def index_weight(company_market_cap, index_total_market_cap): - require_positive("index_total_market_cap", index_total_market_cap) - return company_market_cap / index_total_market_cap - - -def global_lookthrough_weight(index_weight_value, index_share_of_country_market, country_share_of_world_market): - return index_weight_value * index_share_of_country_market * country_share_of_world_market - - -def change_in_listings(start_listings, end_listings): - return end_listings - start_listings - - -def percentage_change(start_value, end_value): - require_positive("start_value", start_value) - return end_value / start_value - 1 - - -def cagr(beginning_value, ending_value, years): - require_positive("beginning_value", beginning_value) - require_positive("years", years) - return (ending_value / beginning_value) ** (1 / years) - 1 diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py deleted file mode 100644 index e593de1a..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py +++ /dev/null @@ -1,22 +0,0 @@ -def investor_friendly_option_pool(existing_shares, investor_target_ownership, target_option_pool): - total_post_money_shares = existing_shares / (1 - investor_target_ownership - target_option_pool) - investor_shares = investor_target_ownership * total_post_money_shares - option_pool_shares = target_option_pool * total_post_money_shares - existing_holder_ownership = existing_shares / total_post_money_shares - return { - "total_post_money_shares": total_post_money_shares, - "investor_shares": investor_shares, - "option_pool_shares": option_pool_shares, - "existing_holder_ownership": existing_holder_ownership, - } - - -def founder_friendly_option_pool(existing_shares, investor_shares, target_option_pool): - total_post_pool_shares = (existing_shares + investor_shares) / (1 - target_option_pool) - option_pool_shares = target_option_pool * total_post_pool_shares - investor_ownership_final = investor_shares / total_post_pool_shares - return { - "total_post_pool_shares": total_post_pool_shares, - "option_pool_shares": option_pool_shares, - "investor_ownership_final": investor_ownership_final, - } diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py deleted file mode 100644 index 2906dad5..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py +++ /dev/null @@ -1,19 +0,0 @@ -def liquidation_preference(investment, liquidation_multiple=1, accrued_dividends=0): - return investment * liquidation_multiple + accrued_dividends - - -def nonparticipating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership): - return max(liquidation_preference_value, as_converted_ownership * exit_value) - - -def participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences): - if exit_value <= total_preferences: - return min(exit_value, liquidation_preference_value) - return liquidation_preference_value + as_converted_ownership * (exit_value - total_preferences) - - -def capped_participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences, cap_multiple, investment): - uncapped = participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences) - capped = min(uncapped, cap_multiple * investment) - converted = as_converted_ownership * exit_value - return max(capped, converted) diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py deleted file mode 100644 index 7e925a81..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py +++ /dev/null @@ -1,48 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def realized_return(price_start, price_end, dividend=0): - require_positive("price_start", price_start) - return (price_end - price_start + dividend) / price_start - - -def expected_return(returns, probabilities): - require_same_length("returns", returns, "probabilities", probabilities) - return sum(probability * return_value for return_value, probability in zip(returns, probabilities)) - - -def variance(returns, probabilities): - mean = expected_return(returns, probabilities) - return sum(probability * (return_value - mean) ** 2 for return_value, probability in zip(returns, probabilities)) - - -def standard_deviation(returns, probabilities): - return sqrt(variance(returns, probabilities)) - - -def historical_average_return(returns): - require_positive("number of returns", len(returns)) - return sum(returns) / len(returns) - - -def portfolio_expected_return(weights, expected_returns): - require_same_length("weights", weights, "expected_returns", expected_returns) - return sum(weight * expected_return_value for weight, expected_return_value in zip(weights, expected_returns)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py deleted file mode 100644 index bf065db7..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py +++ /dev/null @@ -1,41 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def portfolio_variance(weights, covariance_matrix): - rows = len(covariance_matrix) - require_same_length("weights", weights, "covariance_matrix rows", covariance_matrix) - for row in covariance_matrix: - require_same_length("weights", weights, "covariance_matrix row", row) - return sum(weights[i] * weights[j] * covariance_matrix[i][j] for i in range(rows) for j in range(rows)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) - - -def beta(asset_returns, market_returns): - market_variance = covariance(market_returns, market_returns) - require_positive("market variance", market_variance) - return covariance(asset_returns, market_returns) / market_variance - - -def estimate_beta_regression(asset_returns, market_returns, risk_free_rates): - require_same_length("asset_returns", asset_returns, "market_returns", market_returns) - require_same_length("asset_returns", asset_returns, "risk_free_rates", risk_free_rates) - excess_asset = [asset - risk_free for asset, risk_free in zip(asset_returns, risk_free_rates)] - excess_market = [market - risk_free for market, risk_free in zip(market_returns, risk_free_rates)] - return beta(excess_asset, excess_market) diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py deleted file mode 100644 index b8fcc474..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py +++ /dev/null @@ -1,15 +0,0 @@ -from validation import require_positive - - -def safe_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def safe_shares(investment_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return investment_amount / conversion_price - - -def post_money_safe_ownership(investment_amount, post_money_valuation_cap): - require_positive("post_money_valuation_cap", post_money_valuation_cap) - return investment_amount / post_money_valuation_cap diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py deleted file mode 100644 index 6d7850ba..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py +++ /dev/null @@ -1,42 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth, require_same_length - - -def future_value(cash_flow, rate, periods): - return cash_flow * (1 + rate) ** periods - - -def present_value(cash_flow, rate, periods): - return cash_flow / (1 + rate) ** periods - - -def present_value_stream(cash_flows, rate): - return sum(present_value(cash_flow, rate, period) for period, cash_flow in enumerate(cash_flows, start=1)) - - -def present_value_with_spot_rates(cash_flows, spot_rates): - require_same_length("cash_flows", cash_flows, "spot_rates", spot_rates) - return sum(present_value(cash_flow, spot_rate, period) for period, (cash_flow, spot_rate) in enumerate(zip(cash_flows, spot_rates), start=1)) - - -def annuity_pv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * (1 - (1 + rate) ** (-periods)) / rate - - -def annuity_fv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * ((1 + rate) ** periods - 1) / rate - - -def perpetuity_pv(payment, rate): - require_positive("rate", rate) - return payment / rate - - -def growing_perpetuity_pv(next_payment, rate, growth_rate): - require_rate_greater_than_growth(rate, growth_rate) - return next_payment / (rate - growth_rate) diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py deleted file mode 100644 index a94535ec..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py +++ /dev/null @@ -1,33 +0,0 @@ -class FinanceValidationError(ValueError): - """Raised when a finance formula cannot be applied safely.""" - - -def require_positive(name, value): - if value <= 0: - raise FinanceValidationError(f"{name} must be positive.") - return value - - -def require_nonnegative(name, value): - if value < 0: - raise FinanceValidationError(f"{name} must be nonnegative.") - return value - - -def require_rate_greater_than_growth(rate, growth_rate, rate_name="rate"): - if rate <= growth_rate: - raise FinanceValidationError(f"{rate_name} must be greater than growth rate.") - - -def require_same_length(name_a, values_a, name_b, values_b): - if len(values_a) != len(values_b): - raise FinanceValidationError(f"{name_a} and {name_b} must have the same length.") - - -def warn_if(condition, message, warnings=None): - if not condition: - return warnings if warnings is not None else [] - if warnings is None: - warnings = [] - warnings.append(message) - return warnings diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py deleted file mode 100644 index 5c97d94a..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py +++ /dev/null @@ -1,55 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth - - -def value_project_dcf(cash_flows, discount_rate, initial_investment): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def value_company_dcf(free_cash_flows, wacc, terminal_value): - return sum(fcf / (1 + wacc) ** period for period, fcf in enumerate(free_cash_flows, start=1)) + terminal_value / (1 + wacc) ** len(free_cash_flows) - - -def calculate_terminal_value_gordon(fcf_next, wacc, growth_rate): - require_rate_greater_than_growth(wacc, growth_rate, "wacc") - return fcf_next / (wacc - growth_rate) - - -def calculate_terminal_value_exit_multiple(metric, multiple): - return metric * multiple - - -def bridge_enterprise_to_equity_value(enterprise_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def calculate_price_per_share(equity_value, diluted_shares): - require_positive("diluted_shares", diluted_shares) - return equity_value / diluted_shares - - -def run_comparable_company_valuation(company_metric, comparable_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in comparable_multiples] - - -def run_precedent_transaction_valuation(company_metric, transaction_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in transaction_multiples] - - -def calculate_implied_multiple(value, metric): - require_positive("metric", metric) - return value / metric - - -def calculate_implied_value(metric, multiple): - return metric * multiple - - -def run_sensitivity_table(inputs, output_metric): - rows = [] - for case_name, case_inputs in inputs.items(): - rows.append({"case": case_name, "value": output_metric(**case_inputs)}) - return rows - - -def run_scenario_analysis(base_case, upside_case, downside_case): - return {"base": base_case, "upside": upside_case, "downside": downside_case} diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py deleted file mode 100644 index 77d56314..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py +++ /dev/null @@ -1,57 +0,0 @@ -from validation import require_positive - - -def burn_rate(monthly_expenses, monthly_cash_receipts=0): - return monthly_expenses - monthly_cash_receipts - - -def runway(cash_balance, monthly_net_burn): - require_positive("monthly_net_burn", monthly_net_burn) - return cash_balance / monthly_net_burn - - -def vc_target_multiple(required_return, holding_period, probability_success): - require_positive("probability_success", probability_success) - return (1 + required_return) ** holding_period / probability_success - - -def vc_present_value(successful_exit_value, probability_success, required_return, holding_period): - return successful_exit_value * probability_success / (1 + required_return) ** holding_period - - -def vc_total_valuation(successful_exit_value, retention, target_multiple): - require_positive("target_multiple", target_multiple) - return successful_exit_value * retention / target_multiple - - -def vc_partial_valuation(proposed_ownership, total_valuation): - return proposed_ownership * total_valuation - - -def vc_required_ownership(required_investment, total_valuation): - require_positive("total_valuation", total_valuation) - return required_investment / total_valuation - - -def post_money(investment, ownership): - require_positive("ownership", ownership) - return investment / ownership - - -def pre_money(post_money_value, investment): - return post_money_value - investment - - -def price_per_share(pre_money_value, fully_diluted_pre_money_shares): - require_positive("fully_diluted_pre_money_shares", fully_diluted_pre_money_shares) - return pre_money_value / fully_diluted_pre_money_shares - - -def new_shares(investment, price_per_share_value): - require_positive("price_per_share", price_per_share_value) - return investment / price_per_share_value - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares diff --git a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py b/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py deleted file mode 100644 index b147c830..00000000 --- a/.cursor/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py +++ /dev/null @@ -1,9 +0,0 @@ -from validation import require_positive - - -def wacc(equity_value, debt_value, cost_of_equity, cost_of_debt, tax_rate): - total_value = equity_value + debt_value - require_positive("debt plus equity", total_value) - equity_weight = equity_value / total_value - debt_weight = debt_value / total_value - return equity_weight * cost_of_equity + debt_weight * (1 - tax_rate) * cost_of_debt diff --git a/.cursor/skills/productize-financial-markets-context/SKILL.md b/.cursor/skills/productize-financial-markets-context/SKILL.md deleted file mode 100644 index f0ea115f..00000000 --- a/.cursor/skills/productize-financial-markets-context/SKILL.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -name: productize-financial-markets-context -description: >- - Productize Finance context skill for market capitalization, market weights, index - concentration, listed-firm trends, public-company comparables, sector shifts, and CAPM - market-portfolio assumptions. ---- - - - -# Financial Markets Context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `financial-markets-context` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings - -## Purpose - -Market context skill. Use it to interpret public-market facts, index concentration, -listed-firm trends, market capitalization, comparable-company assumptions, sector -shifts, and market portfolio assumptions in CAPM. - -## Core Formulas - -- `Market Cap_i = Share Price_i * Shares Outstanding_i` -- `Weight_i = Market Cap_i / Total Market Cap` -- `Index Weight_i = Market Cap_i / sum(Market Cap of All Index Constituents)` -- `Global Weight_i = index weight * index share of country market * country share of world market` -- `Change in Listings = Listings_End - Listings_Start` -- `% Change = (End / Start - 1) * 100` -- `CAGR = (Ending Value / Beginning Value)^(1 / Years) - 1` - -## Interpretation Rules - -- Fewer listed firms does not necessarily mean a smaller equity market. -- Market capitalization can rise even if listings fall. -- This can happen because public firms become larger, smaller firms delist, and mergers concentrate value. -- Index concentration matters because the CAPM market portfolio is value-weighted. -- Public comparables may be biased if the target is much smaller, less mature, less profitable, or in a different sector. -- Sector composition changes over time, so historical index returns may reflect sector shifts, not only broad economic growth. - -## Required Validation - -- Warn if equal weighting is confused with value weighting. -- Warn if index concentration is ignored. -- Warn if public comparables are used for a startup without maturity adjustments. -- Warn if global market assumptions use only one domestic index. -- Warn if stale market weights are used. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Separate market fact, valuation implication, and comparability risk. diff --git a/.cursor/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md b/.cursor/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md deleted file mode 100644 index 55ad6c4c..00000000 --- a/.cursor/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md +++ /dev/null @@ -1,422 +0,0 @@ ---- -name: productize-fragmented-user-research-synthesis-into-coherent-insights -description: >- - Fragmented user research synthesis into coherent insights. Use when the user needs a product - workflow for user research related to fragmented user research synthesis into coherent - insights. Trigger terms: user-research, synthesis, insights. ---- - - - -# Fragmented user research synthesis into coherent insights - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `fragmented-user-research-synthesis-into-coherent-insights` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Fragmented user research synthesis into coherent insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{RESEARCH_INPUTS}} -- {{PRODUCT_CONTEXT}} -- {{DESIGN_QUESTIONS}} -- {{CURRENT_ASSUMPTIONS}} -- {{BUSINESS_GOALS}} - - -GOAL -Produce a high-quality deliverable for: Fragmented user research synthesis into coherent insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Synthesize fragmented research inputs into coherent, evidence-based insights that inform design and product decisions. -- Use the provided inputs: -- `{{RESEARCH_INPUTS}}` -- `{{PRODUCT_CONTEXT}}` -- `{{DESIGN_QUESTIONS}}` -- `{{CURRENT_ASSUMPTIONS}}` -- `{{BUSINESS_GOALS}}` -- Perform synthesis rigorously: -- Inventory and assess source quality/coverage. -- Extract coded observations (quotes, behaviors, themes, segment/context metadata). -- Identify cross-source patterns and contradictions. -- Assign confidence levels with explicit rationale. -- Map insights to JTBD and user-needs hierarchy. -- Link insights directly to design questions and actionable recommendations. -- Identify research gaps, unresolved assumptions, and prioritized follow-up research. -- Keep evidence traceable, avoid over-generalization, and state assumptions/uncertainties explicitly. - -FORMAT -Return exactly this structure: - - - -**Data Sources Summary:** -- User interviews: [X participants] covering [topics, user segments, dates] -- Support tickets: [Y tickets] from [date range] about [primary themes] -- NPS feedback: [Z responses] with [average score] discussing [key topics] -- Usage analytics: [data range, key metrics, user actions analyzed] -- Feature requests: [count] requests across [platforms/sources] -- Usability tests: [sessions count] testing [specific flows or features] -- Survey data: [respondents count] on [topics covered] -- Anecdotal feedback: [source count] from [stakeholders, channels] -- Session recordings: [count] sessions showing [behaviors] -- Other sources: [specify any additional data] - -**Data Quality Assessment:** -- Time range: [how recent is this data?] -- User segment coverage: [which personas/segments are represented?] -- Sample size adequacy: [sufficient for confidence in findings?] -- Potential bias: [what perspectives might be over/under-represented?] -- Data completeness: [what's missing or sparse?] - - - - -**Insight Statement:** -[One clear, specific sentence stating what you learned about users] - -**Evidence:** -- User interviews: "[verbatim quote]" (Participant X, [segment]) -- Support tickets: [Y tickets] report "[specific issue]" with keywords: [terms] -- NPS feedback: "[example comment]" (common theme in Z% of detractor responses) -- Analytics data: [X% of users] exhibit [specific behavior], [frequency/context] -- Additional evidence: [any other supporting data points] - -**Confidence Level:** High / Medium / Low -**Rationale for Confidence:** [Why you assigned this confidence level] - -**User Segments Affected:** -- [Segment 1]: [how this manifests for them] -- [Segment 2]: [how this manifests for them] - -**Jobs-to-be-Done Connection:** -[Which job is this insight related to? How does it help or hinder job completion?] - -**Design Implications:** -- Consider: [specific design approach this suggests] -- Avoid: [what this insight argues against] -- Prioritize: [which aspect of the experience to focus on] -- Measure: [how to validate design addressed this insight] - -**Related Patterns:** -[Which other insights connect to this? How do they reinforce or complicate each other?] - -**Business Impact:** -[How does addressing this insight connect to business goals or metrics?] - - - -[Repeat the full structure for 5-10 key insights, maintaining consistent depth and evidence rigor] - - - -[Continue for all major insights...] - - - - -**Conflict 1:** -- Signal A: [what one source or segment indicates] -- Signal B: [what contradicts this] -- Possible explanations: - * [Explanation 1: e.g., different user segments with different needs] - * [Explanation 2: e.g., stated preference vs. actual behavior] - * [Explanation 3: e.g., context-dependent variation] -- Recommended resolution: [What research or analysis would clarify this?] -- Design strategy given conflict: [How to proceed despite uncertainty?] - -**Conflict 2:** -[Repeat structure for each major contradiction in the data] - -**Synthesis:** -[What do these conflicts reveal about user diversity, product complexity, or research gaps?] - - - -**Question 1:** [Restate the first design question] -- **Answer based on research:** [What the data tells you] -- **Supporting insights:** [Which insights from above inform this answer] -- **Confidence level:** High / Medium / Low -- **Caveats and limitations:** [What qualifies or nuances this answer] -- **What we still don't know:** [Gaps specific to this question] -- **Recommended action:** [What to design/test/research next] - -**Question 2:** [Restate the second design question] -[Repeat structure for each design question provided] - -**New Questions Surfaced:** -[Design questions that emerged from the research but weren't originally asked] - - - - -**Must-Have Needs (Strong Evidence, High Impact):** -1. [Need 1]: [description] - - Evidence: [cross-source validation] - - If unmet: [severe user/business consequence] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat structure for 3-5 critical needs] - - - -**Should-Have Needs (Moderate Evidence, Meaningful Impact):** -1. [Need 1]: [description] - - Evidence: [validation from 1-2 strong sources] - - If unmet: [moderate user friction or business impact] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat for 5-8 important needs] - - - -**Nice-to-Have Needs (Weak Signal, Low/Uncertain Impact):** -1. [Need 1]: [description] - - Evidence: [limited mentions or single source] - - Potential value: [why this might matter despite weak signal] - - Validation needed: [how to test if this is actually important] - -2. [Need 2]: [description] - [Repeat for 3-5 nice-to-have needs] - - - -**Segment-Specific Needs:** -- [Segment A]: [unique needs not shared by other segments] -- [Segment B]: [unique needs not shared by other segments] -- [Universal needs]: [needs expressed across all segments] - - - - -**Current Workflows and Workarounds:** -[Describe how users actually accomplish tasks today, including inefficient or creative workarounds that reveal unmet needs] - -**Decision-Making Patterns:** -[How users make choices within the product, what information they seek, what causes hesitation or confidence] - -**Pain Point Triggers:** -[Specific circumstances, contexts, or actions that consistently lead to user frustration] - -**Success Patterns:** -[When and how users successfully achieve their goals, what enables their success] - -**Usage Context and Frequency:** -[When, where, why, and how often users engage with the product or specific features] - -**Adoption and Learning Patterns:** -[How users onboard themselves, what helps or hinders learning, common confusion points] - -**Abandonment and Recovery Patterns:** -[What causes users to give up, what brings them back, how they recover from errors] - -**Cross-Tool Workflows:** -[How users combine your product with other tools, what gaps force tool-switching] - - - -**Primary Functional Jobs:** -1. [Job]: When [situation], I want to [motivation], so I can [expected outcome] - - Evidence: [how research revealed this job] - - Current obstacles: [what prevents job completion] - - Success criteria: [how users define successful job completion] - -2. [Job]: [Repeat structure for 3-5 primary jobs] - -**Emotional Jobs:** -- [Feel]: [emotion users want to feel, e.g., "feel confident in my decisions"] -- [Avoid]: [emotion users want to avoid, e.g., "avoid feeling overwhelmed"] -- Evidence: [quotes, observations, sentiment indicators] - -**Social Jobs:** -- [Perception]: [how users want to be seen, e.g., "be perceived as data-driven"] -- [Context]: [social situations where product use matters] -- Evidence: [research indicators of social motivations] - -**Related Jobs in the Consumption Chain:** -- Before main job: [how users discover, evaluate, and choose the product] -- After main job: [how users share, report, or build on outcomes] -- Maintenance jobs: [ongoing tasks to keep getting value] - - - - -**Critical Unknowns (Blocking Design Decisions):** -1. [Question]: [why this matters for design] -2. [Question]: [why this matters for design] -3. [Question]: [why this matters for design] - -**Important Unknowns (Would Significantly Inform Design):** -1. [Question]: [how this would help] -2. [Question]: [how this would help] - -**Curiosities (Interesting But Not Urgent):** -1. [Question]: [potential value] -2. [Question]: [potential value] - - - -**Research Activity 1:** -- **Method:** [interviews / usability testing / survey / analytics deep-dive / diary study / etc.] -- **Target participants:** [which user segments, how many, recruitment criteria] -- **Key questions to answer:** [specific questions this research would resolve] -- **Expected outcomes:** [what you'll learn and how it informs design] -- **Effort estimate:** [time and resources required] -- **Priority:** High / Medium / Low - [rationale] - -**Research Activity 2:** -[Repeat structure for 3-5 recommended research activities, prioritized by impact and urgency] - - - -**Design Assumptions:** -1. [Assumption about user behavior or preferences]: Currently [validated / unvalidated / contradicted] by research -2. [Assumption about priorities or needs]: Currently [status] -3. [Assumption about technical or business constraints]: Currently [status] - -**Team Assumptions:** -[Assumptions stakeholders or team members hold that aren't supported by dataโ€”list with gentle evidence-based reframing] - -**Testing Strategy:** -[How to quickly validate or invalidate the most critical assumptions through lightweight tests] - - - - -**Priority 1 Recommendations (Supported by High-Confidence Insights):** -1. [Specific design action]: [rationale tied to insight X, Y, Z] - - Expected impact: [user and business outcomes] - - Success metrics: [how to measure if this worked] - -2. [Specific design action]: [rationale tied to insights] - [Repeat for 3-5 top-priority recommendations] - -**Priority 2 Recommendations (Supported by Medium-Confidence Insights):** -1. [Specific design action]: [rationale] - [Repeat for 5-7 secondary recommendations] - -**Quick Wins (Low Effort, Clear User Value):** -1. [Specific design action]: [why this is easy and valuable] - [Repeat for 3-5 quick wins] - -**Strategic Bets (Lower Confidence, High Potential):** -1. [Specific design action]: [why worth exploring despite uncertainty] - - Validation approach: [how to test before full commitment] - [Repeat for 2-3 strategic bets] - -**Do Not Pursue:** -[Features, changes, or directions that research argues against, with rationale] - - - -**Executive Summary** - -**What We Learned:** -[2-3 sentences capturing the most important insights from the research] - -**User Needs Priority:** -Users critically need [top need], strongly want [second need], and would appreciate [third need]. The evidence is strongest for [insight area] and weakest for [insight area requiring validation]. - -**Key Behavioral Patterns:** -[1-2 sentences on how users actually behave vs. what we might have assumed] - -**Design Implications:** -The research strongly supports [recommended direction 1] and [recommended direction 2], while arguing against [current assumption or planned direction]. We should prioritize [specific user segment or job-to-be-done] because [evidence-based rationale]. - -**Critical Unknowns:** -We still need to understand [key gap 1] and [key gap 2] through [recommended research method]. - -**Recommended Next Steps:** -1. [Immediate action based on high-confidence insights] -2. [Design exploration for medium-confidence opportunities] -3. [Targeted research to fill critical gaps] - -**Business Impact:** -Addressing these insights is expected to improve [business metric] by [directional estimate] because [user behavior change expected]. - -[Total: 250-350 words] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Insights are not supported by cross-source evidence or confidence rationale. -- Contradictions are ignored or not addressed with a resolution approach. -- Recommendations are not prioritized or not linked to synthesized insights/business goals. -- Research gaps and assumption validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md b/.cursor/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md deleted file mode 100644 index fc5dbcfc..00000000 --- a/.cursor/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -name: productize-framework-application-to-product-challenges-from-user-input -description: >- - Framework application to product challenges from user input. Use when the user needs a - product workflow for product strategy related to framework application to product challenges - from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching. ---- - - - -# Framework application to product challenges from user input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `framework-application-to-product-challenges-from-user-input` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Framework application to product challenges from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRAMEWORK}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Framework application to product challenges from user input. -Success metric: -- Asks targeted questions when key context is missing. -- Applies the provided framework precisely to the userโ€™s situation. -- Produces actionable advice and a clear recommendation when sufficient context exists. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{FRAMEWORK}}` and `{{USER_INPUT}}`; if key context is missing, ask targeted questions first. -- Do not summarize the framework back to the user. -- When asking for more information, use `` tags only. -- When providing guidance, use `` tags only. -- When providing a final recommendation, use `` tags only. -- Keep advice specific and grounded in the userโ€™s context; avoid generic PM guidance. - -FORMAT -Return exactly this structure: - - -[Targeted questions needed to apply the framework] - - - -[Framework-applied guidance once sufficient context exists] - - - -[Final recommendation when enough context exists] - - -FAILURE -- Required tags are missing or malformed. -- Output includes framework summary instead of application. -- Advice is generic or not tied to the user input. -- Recommendation is provided without sufficient context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-frontend-design/SKILL.md b/.cursor/skills/productize-frontend-design/SKILL.md deleted file mode 100644 index b21a1c23..00000000 --- a/.cursor/skills/productize-frontend-design/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-frontend-design -description: >- - Design implementation-ready frontend solutions with UX intent, component structure, - responsive behavior, accessibility, and handoff criteria. ---- - - - -# Frontend Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `frontend-design` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to design frontend behavior and UI structure before or alongside implementation. - -## The Process - -### Step 1: Define UX objective - -Capture: -- user goal -- primary user flow -- success state and failure states - -### Step 2: Specify UI architecture - -Define: -- screen/layout structure -- component hierarchy -- state model (loading, empty, error, success) - -### Step 3: Specify design system decisions - -Set: -- typography and spacing rules -- color/contrast constraints -- interaction patterns - -### Step 4: Specify responsive and accessibility requirements - -Include: -- breakpoints and behavior changes -- keyboard navigation expectations -- ARIA/semantic requirements -- contrast and focus visibility requirements - -### Step 5: Define implementation handoff - -Provide: -- component list and props/state contract -- acceptance criteria -- verification checklist - -## Output Format - -```markdown -# [Feature Name] Frontend Design Spec - -## UX Objective -- User goal: -- Primary flow: -- Success/failure states: - -## UI Architecture -- Layout: -- Component hierarchy: -- State model: - -## Responsive Behavior -- Desktop: -- Tablet: -- Mobile: - -## Accessibility Requirements -- Keyboard: -- Semantics/ARIA: -- Contrast/focus: - -## Handoff -- Components to implement: -- Acceptance criteria: -- Verification checklist: -``` - -## Quality Bar - -- Design decisions must map to user goals -- Accessibility section is mandatory -- Handoff must be implementable without extra interpretation - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/.cursor/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md b/.cursor/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md deleted file mode 100644 index 62097374..00000000 --- a/.cursor/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: productize-future-product-opportunities-from-market-inflection-points -description: >- - Future product opportunities from market inflection points. Use when the user needs a - product workflow for product strategy related to future product opportunities from market - inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, - trends, product-vision. ---- - - - -# Future product opportunities from market inflection points - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `future-product-opportunities-from-market-inflection-points` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Future product opportunities from market inflection points**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_YEAR}} -- {{RESEARCH_TIMEFRAME}} - - -GOAL -Produce a high-quality deliverable for: Future product opportunities from market inflection points. -Success metric: -- Identifies concrete regulatory, technological, and belief inflection points within the stated timeframe. -- Connects converging trends to 3โ€“5 plausible future opportunities. -- Provides actionable challenges and timelines for each opportunity. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_YEAR}}` and `{{RESEARCH_TIMEFRAME}}`; if context is missing, state assumptions explicitly. -- List 3โ€“5 items per inflection category (regulatory, technological, belief). -- Provide 3โ€“5 converging trend sets that explicitly combine at least two categories. -- Provide 3โ€“5 future opportunities with concept, enabling trends, challenges, and timeline. -- Keep opportunities plausible within the specified research timeframe. - -FORMAT -Return exactly this structure: - - -1. Inflection Points: - a. Regulatory: - - [List 3โ€“5 significant regulatory changes] - b. Technological: - - [List 3โ€“5 important technological advancements] - c. Belief: - - [List 3โ€“5 notable shifts in societal attitudes or behaviors] - -2. Converging Trends: - - [Describe 3โ€“5 sets of converging trends, explaining how they intersect] - -3. Future Opportunities: - [For each opportunity (aim for 3โ€“5), include:] - a. Concept: [Brief description] - b. Enabling Trends: [List the key inflection points or converging trends] - c. Challenges: [Potential barriers or difficulties] - d. Timeline: [Estimated timeframe for realization] - -4. Conclusion: - [Summarize the most promising areas for innovation based on your analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any inflection category has fewer than 3 or more than 5 items. -- Converging trends do not combine multiple categories. -- Opportunities are missing required fields or outside the specified timeframe. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-group-decision-making-quality-review/SKILL.md b/.cursor/skills/productize-group-decision-making-quality-review/SKILL.md deleted file mode 100644 index cb5bacdc..00000000 --- a/.cursor/skills/productize-group-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: productize-group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, or - operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group - decides. ---- - - - -# Group Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `group-decision-making-quality-review` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/.cursor/skills/productize-grow/SKILL.md b/.cursor/skills/productize-grow/SKILL.md deleted file mode 100644 index c1b5d4fb..00000000 --- a/.cursor/skills/productize-grow/SKILL.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: productize-grow -description: >- - Productize grow playbook for stable products with activation evidence. Use when the product - has a working core and the team needs growth diagnosis, growth loops, GTM choices, - onboarding, retention, pricing, lifecycle triggers, and experiment cadence. ---- - - - -# Productize Grow - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `grow` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition - -Use this playbook when the core product is stable enough to grow. Grow is not the -place to invent the product; use `$0-1` for new bets and `$operate` for continuous -production health. - -## Cadence - -- Trigger: stable activation, repeat usage, clear ICP, or a growth bottleneck. -- Rhythm: weekly experiment planning and readout, with metric reviews before changing - channels, onboarding, pricing, or lifecycle triggers. -- Closure: target hit, target abandoned, strategy pivot, or evidence that the product - needs a new `$0-1` loop. - -## Route Internally - -- Product-market fit and bottlenecks: `$product-market-fit-cycle`, `$aarrr-growth-diagnostics`, `$metrics-review` -- Loops and experiments: `$growth-loops`, `$plg-growth-playbook`, `$growth-project-generation-with-pioneer-migrator-settler`, `$robust-experiment-design-from-goals-and-systems` -- GTM and lifecycle: `$gtm-motions`, `$gtm-strategy`, `$onboarding-flow-optimization-from-product-data-to-user-success` -- Retention and monetization: `$churn-reduction-from-customer-data-and-exit-survey-analysis`, `$pricing-strategy`, `$monetization-strategy` -- Gates: `$product-review`, `$qa`, `$comms-review`, `$docs`, `$release` - -## Required Output - -Return: - -1. **Growth State**: ICP, activation evidence, retention signal, bottleneck, and metric caveats. -2. **Growth Thesis**: target, growth loop, channel or lifecycle trigger, and why it fits the current evidence. -3. **Experiment Cadence**: tests, owners, sample size or evidence threshold, and stop/pivot rules. -4. **Gate Calls**: product, QA, docs, release, or comms gates needed before launch. -5. **Closure Condition**: target hit, pivot, pause, or new `$0-1` bet. diff --git a/.cursor/skills/productize-growth-loops/SKILL.md b/.cursor/skills/productize-growth-loops/SKILL.md deleted file mode 100644 index 4f439fbc..00000000 --- a/.cursor/skills/productize-growth-loops/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: productize-growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- - - - -# Growth Loops - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-loops` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.cursor/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md b/.cursor/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md deleted file mode 100644 index 4c847103..00000000 --- a/.cursor/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-growth-project-generation-with-pioneer-migrator-settler -description: >- - Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a - product workflow for product strategy related to growth project generation with - pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, - portfolio. ---- - - - -# Growth project generation with Pioneer-Migrator-Settler framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-project-generation-with-pioneer-migrator-settler` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Growth project generation with Pioneer-Migrator-Settler framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY}} - - -GOAL -Produce a high-quality deliverable for: Growth project generation with Pioneer-Migrator-Settler framework. -Success metric: -- Produces 12 distinct growth projects categorized into Pioneer/Migrator/Settler. -- Ensures balanced portfolio logic and a brief plan to drive growth. -- Keeps ideas concrete, differentiated, and aligned to the company context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY}}`; if details are missing, state assumptions explicitly. -- Generate exactly 12 distinct growth projects: - - 3 creative, - - 3 weird, - - 3 compelling, - - 3 novel and unexpected. -- Each idea must be tagged as one of: Pioneer, Migrator, Settler. -- Keep ideas concrete and specific to the companyโ€™s context. -- Provide a brief analysis of portfolio balance and strategic impact. -- Provide a short growth plan for how to build new market space and profitable growth. - -FORMAT -Return exactly this structure: - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - - -[Brief analysis of mix and impact, with portfolio balance insights] - - - -[Brief plan for creating new market space and profitable growth] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer or more than 12 ideas are provided. -- Any idea is missing a Pioneer/Migrator/Settler category. -- Ideas are generic or not grounded in the company context. -- Analysis or growth plan is missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md b/.cursor/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md deleted file mode 100644 index 99d9f24c..00000000 --- a/.cursor/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: productize-growth-strategy-synthesis-from-user-inputs -description: >- - Growth strategy synthesis from user inputs. Use when the user needs a product workflow for - product strategy related to growth strategy synthesis from user inputs. Trigger terms: - growth, strategy, experimentation, metrics, distribution. ---- - - - -# Growth strategy synthesis from user inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-strategy-synthesis-from-user-inputs` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth strategy brief with bets, loops, experiments, and metrics - -Use this skill to run the Productize prompt contract for **Growth strategy synthesis from user inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUTS}} - - -GOAL -Produce a high-quality deliverable for: Growth strategy synthesis from user inputs. -Success metric: -- Produces a complete growth strategy across model, constraints, horizon, method, principle, and catalyst. -- Grounds all recommendations in the provided user inputs. -- Outputs actionable, testable recommendations and a concise summary. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUTS}}`; if critical data is missing, state assumptions explicitly. -- Address each required section: model, constraint, horizon, method, principle, catalyst, summary. -- Keep recommendations actionable and testable; avoid generic advice. -- If quantitative data is present, reference it; if not, use qualitative reasoning and label assumptions. - -FORMAT -Return exactly this structure: - - - -[Provide a detailed description of the growth model] - - - -[Identify and explain the main growth constraints] - - - -[Analyze the growth horizon and potential limitations] - - - -[Propose specific methods to address constraints and extend the growth horizon] - - - -[Develop a guiding principle for aligning the organization] - - - -[Identify and explain any growth catalysts] - - - -[Provide a brief summary of the overall growth strategy] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Recommendations are not tied to the provided inputs. -- Growth method lacks actionable steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-gtm-motions/SKILL.md b/.cursor/skills/productize-gtm-motions/SKILL.md deleted file mode 100644 index a9650ffb..00000000 --- a/.cursor/skills/productize-gtm-motions/SKILL.md +++ /dev/null @@ -1,236 +0,0 @@ ---- -name: productize-gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, - partner, ABM, or hybrid go-to-market motions. ---- - - - -# GTM Motions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-motions` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.cursor/skills/productize-gtm-strategy/SKILL.md b/.cursor/skills/productize-gtm-strategy/SKILL.md deleted file mode 100644 index 22360c0b..00000000 --- a/.cursor/skills/productize-gtm-strategy/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: productize-gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- - - - -# GTM Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.cursor/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md b/.cursor/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md deleted file mode 100644 index 5d62c3c7..00000000 --- a/.cursor/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- - - - -# Ideal Customer Profile (ICP) representative for X product - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideal-customer-profile-icp-representative-for-x-product` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.cursor/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md b/.cursor/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md deleted file mode 100644 index 3be9171c..00000000 --- a/.cursor/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md +++ /dev/null @@ -1,171 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make ICP outputs sharper on demographics, behaviors, JTBD, PMF evidence, and best-customer patterns. - -## Routing Signals - -- ideal customer profile -- icp -- pmf survey -- best customers - -## pm-go-to-market/skills/ideal-customer-profile/SKILL.md - -## Overview -Identify your Ideal Customer Profile (ICP) from research and survey data. This skill synthesizes customer research to define the customer most likely to find value, retain, and expand with your product. - -## When to Use -- Defining ICP from product-market fit survey data -- Targeting high-value customer segments -- Analyzing customer success and expansion patterns -- Prioritizing sales and marketing efforts -- Evaluating new customer opportunities for fit -- Refining target market definition - -## ICP Framework Components - -### Demographics -Who are they from a firmographic and personal perspective? -- Company size (employees, revenue) -- Industry or vertical -- Geographic location -- Job title and department -- Years of experience in role -- Education and background -- Organizational structure and reporting - -### Behaviors -How do they work and make decisions? -- How they discover and evaluate solutions -- Buying process and decision-making timeline -- Technical literacy and product adoption speed -- Collaboration style (solo decision vs committee) -- Change management and adoption style -- Tool switching frequency -- Community involvement and peer influence - -### Jobs to Be Done (JTBD) -What are they trying to accomplish? -- Primary job/goal they're trying to achieve -- Secondary jobs that support the primary job -- Emotional jobs (how they want to feel) -- Social jobs (status and perception) -- Jobs they avoid or want to eliminate -- Frequency and importance of each job -- Success metrics for completing job - -### Needs and Pain Points -What problems does your product solve? -- Specific pain points they experience -- Current workarounds and limitations -- Impact on productivity or outcomes -- Cost or time burden of the problem -- Emotional frustration levels -- Barriers to solving the problem -- Available budget to solve -- Competing priorities - -## How It Works - -### Step 1: Gather Customer Data -Collect research about actual and potential customers: -- Product-market fit survey responses -- Customer interview transcripts -- Trial or freemium user behavior data -- Customer feedback and support tickets -- Churn analysis and customer lifecycle data -- Win/loss analysis from sales -- Competitor customer analysis - -### Step 2: Segment by Value -Identify customer cohorts and their value: -- Highest LTV (lifetime value) customers -- Fastest time-to-value customers -- Lowest churn rate customers -- Highest expansion/upsell customers -- Most enthusiastic/engaged customers -- Best reference/case study potential -- Most aligned with product vision - -### Step 3: Profile Demographics -Extract firmographic patterns: -- Common company sizes (employee count, revenue) -- Industry verticals and sub-verticals -- Geographic concentrations -- Typical department and reporting structure -- Budget holders and budget available -- Company stage (startup, growth, enterprise) -- Company culture indicators - -### Step 4: Identify Behaviors -Map decision-making and adoption patterns: -- How they discovered your product (channel) -- Evaluation process and timeline -- Key stakeholders in decision -- Obstacles during sales process -- Product adoption speed and breadth -- Team involvement in onboarding -- Frequency of feature usage -- Support and service needs - -### Step 5: Define JTBD -Articulate what they're trying to accomplish: -- Primary job/goal (functional job) -- Emotional dimensions (how they want to feel) -- Social dimensions (team and stakeholder impact) -- Success metrics (how they measure success) -- Context and constraints (when, where, with whom) -- Competing jobs and priorities -- Importance ranking of various jobs - -### Step 6: Document Pain Points and Needs -Synthesize specific problem areas: -- Before state (current situation and frustrations) -- Desired after state (ideal future state) -- Gap size and impact quantification -- Emotional dimensions of the problem -- Resource constraints preventing solutions -- Skepticism or hesitations -- Success criteria for solution - -## Input Format -Use $ARGUMENTS to pass: -- Research data (surveys, interviews, transcripts) -- Customer success/metrics data -- Product usage analytics -- Sales activity and win/loss data -- Existing customer database -- Competitive intelligence - -## Output -A comprehensive ICP definition including: -- Firmographic profile (company size, industry, location) -- Behavioral profile (buying patterns, adoption style) -- Complete JTBD mapping (functional, emotional, social jobs) -- Top 5-7 pain points and specific needs -- Quantified impact metrics (cost of problem, value of solution) -- Decision-making process and key stakeholders -- Typical customer journey and timeline -- Go-to-market implications and messaging -- Disqualification criteria (who is NOT a good fit) -- High-value segment within ICP (ideal-of-the-ideal) - -## Framework -Based on Jobs to Be Done theory by Clayton Christensen and customer profiling methodology. Combines behavioral data with motivational insights to define actionable customer profiles. - -## Tips -- Use quantitative and qualitative data together -- Interview 10+ high-value customers for pattern identification -- Look for non-obvious demographic patterns (outliers can be high-value) -- Define both ideal ICP and acceptable secondary segments -- Revisit ICP quarterly as you gather more customer data -- Use ICP to evaluate all new sales opportunities -- Share ICP across entire organization (marketing, sales, product) -- Remember: ICP should drive focus, not exclude all others - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/.cursor/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md b/.cursor/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md deleted file mode 100644 index 34c8b07f..00000000 --- a/.cursor/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem -description: >- - Ideas for affordances and signifiers based on a design problem. Use when the user needs a - product workflow for design & prototyping related to ideas for affordances and signifiers - based on a design problem. Trigger terms: ux, interaction-design, affordances, usability. ---- - - - -# Ideas for affordances and signifiers based on a design problem - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideas-for-affordances-and-signifiers-based-on-a-design-problem` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Ideas for affordances and signifiers based on a design problem**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_CHALLENGE}} - - -GOAL -Produce a high-quality deliverable for: Ideas for affordances and signifiers based on a design problem. -Success metric: -- Identifies key user interactions in the design challenge before proposing ideas. -- Produces at least 5 concrete ideas each for affordances, perceived affordances, and signifiers. -- Each idea includes a brief explanation tied to the challenge and UX impact. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DESIGN_CHALLENGE}}`; if context is incomplete, state assumptions explicitly. -- Start with a brief interaction analysis identifying main user functions/tasks. -- Generate at least 5 ideas in each category: affordances, perceived affordances, signifiers. -- For every idea, include a short explanation linking: - - the specific challenge friction/opportunity, - - how the idea guides user action or perception, - - expected UX improvement. -- Keep ideas practical, non-generic, and directly relevant to the described product context. - -FORMAT -Return exactly this structure: - - - -[Main user interactions/functions required by the challenge] - - - -1. [Affordance idea] - [Brief explanation] -2. [Affordance idea] - [Brief explanation] -3. [Affordance idea] - [Brief explanation] -4. [Affordance idea] - [Brief explanation] -5. [Affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Perceived affordance idea] - [Brief explanation] -2. [Perceived affordance idea] - [Brief explanation] -3. [Perceived affordance idea] - [Brief explanation] -4. [Perceived affordance idea] - [Brief explanation] -5. [Perceived affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Signifier idea] - [Brief explanation] -2. [Signifier idea] - [Brief explanation] -3. [Signifier idea] - [Brief explanation] -4. [Signifier idea] - [Brief explanation] -5. [Signifier idea] - [Brief explanation] -[Optional additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 5 ideas in any required category. -- Explanations are missing for one or more ideas. -- No interaction analysis is provided before idea lists. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-implementation-notes/SKILL.md b/.cursor/skills/productize-implementation-notes/SKILL.md deleted file mode 100644 index 6da03e47..00000000 --- a/.cursor/skills/productize-implementation-notes/SKILL.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: productize-implementation-notes -description: >- - Running implementation-notes protocol for spec-driven builds. Use when the user asks the - agent to maintain implementation-notes.md or implementation-notes.html with decisions, - deviations, tradeoffs, open questions, and verification while implementing a feature, fix, - or product slice. ---- - - - -# Implementation Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `implementation-notes` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence - -Use this skill when implementation work needs a durable notes artifact that keeps -the user in the loop without stopping progress for every ambiguity. - -This is not a verbose work log. It records the meaningful places where the spec -was interpreted, narrowed, changed, or found incomplete. - -## Activation - -Activate alongside `$tdd`, `$eng-review`, `$qa`, or `$verification` when the user -asks for any of: - -- `implementation-notes.md` -- `implementation-notes.html` -- running implementation notes -- decisions the spec did not cover -- deviations from the spec -- tradeoffs made during implementation -- open questions to confirm after implementation - -Do not ask whether to create the file if the user already requested it. Create or -update the requested file and keep working. - -## File Selection - -- Use the exact path and format the user requested. -- If the user asks for notes but does not name a file, use `implementation-notes.md`. -- If the user asks for HTML, use `implementation-notes.html`. -- If an implementation-notes file already exists for the current task, update it - instead of overwriting useful existing context. - -## Update Cadence - -1. Create the notes file before or during the first implementation decision. -2. Update it when the implementation makes a non-obvious choice, interprets an - ambiguous spec line, departs from the spec, accepts a tradeoff, discovers an - open question, or changes verification scope. -3. Batch small related choices into one entry instead of writing noisy micro-logs. -4. Before claiming completion, do a final pass that aligns notes with the actual - diff, verification evidence, and unresolved questions. - -## What To Capture - -### Design Decisions - -Choices made where the spec was ambiguous or silent. - -Each entry should include: - -- decision -- reason -- spec basis, or `unspecified` -- impact - -### Deviations - -Intentional departures from the spec. - -Each entry should include: - -- requested behavior -- implemented behavior -- reason -- impact -- whether user confirmation is needed - -### Tradeoffs - -Alternatives considered and why the chosen path is better for this slice. - -Each entry should include: - -- chosen option -- alternatives considered -- why chosen -- cost or downside accepted - -### Open Questions - -Questions the user may want to confirm or revise. - -Each entry should include: - -- question -- why it matters -- current default assumption -- status: `needs-review`, `accepted-risk`, `resolved`, or `deferred` - -### Verification - -Evidence that proves the implementation and the notes are current. - -Include: - -- commands or checks run -- result -- coverage gaps -- behavior not tested - -## What Not To Capture - -- Every file edit. -- Internal reasoning or chain-of-thought. -- Obvious implementation details already specified. -- Secrets, credentials, private customer data, or raw logs with sensitive content. -- Generic progress narration that does not help the user review decisions. - -## Markdown Template - -Use this structure for Markdown notes: - -```markdown -# Implementation Notes - -## Spec Reference -[Feature, ticket, prompt, or artifact being implemented.] - -## Summary -[One paragraph describing how the implementation interprets the spec.] - -## Design Decisions -| Decision | Reason | Spec basis | Impact | -|---|---|---|---| - -## Deviations -| Requested | Implemented | Why | Impact | Confirmation | -|---|---|---|---|---| - -## Tradeoffs -| Choice | Alternatives | Why this path | Downside | -|---|---|---|---| - -## Open Questions -| Question | Why it matters | Current assumption | Status | -|---|---|---|---| - -## Verification -| Check | Result | Notes | -|---|---|---| -``` - -## HTML Template Rules - -For `implementation-notes.html`, produce a single self-contained HTML file: - -- embedded CSS and JavaScript only -- no external assets or remote dependencies unless explicitly requested -- semantic headings and landmarks -- responsive layout -- decision cards or tables for scanability -- status chips for `needs-review`, `accepted-risk`, `resolved`, and `deferred` -- a clear verification section near the bottom -- optional filters, collapsible detail, or copy buttons only when they help review - -Recommended HTML sections: - -1. **Header**: spec reference, implementation status, last updated, owner if known. -2. **Decision Dashboard**: counts for decisions, deviations, tradeoffs, open questions. -3. **Design Decisions**: cards or table with reason, spec basis, and impact. -4. **Deviations**: requested vs implemented, why, impact, confirmation status. -5. **Tradeoffs**: comparison table with accepted downside. -6. **Open Questions**: status and current default assumption. -7. **Verification**: commands/checks, results, and gaps. - -## Route Internally - -- `$tdd` -- `$eng-review` -- `$qa` -- `$verification` -- `$docs` -- `$release` - -## Required Output - -Return: - -1. **Notes File**: path, format, and whether it was created or updated. -2. **Captured Decisions**: decisions, deviations, tradeoffs, and open questions added. -3. **Spec Impact**: what downstream product, design, eng, QA, release, docs, or DX work may change. -4. **Verification Linkage**: checks run, gaps, and whether the notes match the final implementation. -5. **Next Review**: user confirmations or gate follow-ups needed. diff --git a/.cursor/skills/productize-industry-trend-strategy/SKILL.md b/.cursor/skills/productize-industry-trend-strategy/SKILL.md deleted file mode 100644 index 28c42dff..00000000 --- a/.cursor/skills/productize-industry-trend-strategy/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: productize-industry-trend-strategy -description: >- - Industry trend strategy. Use when the user needs a product workflow for product strategy - related to industry trend strategy. Trigger terms: strategy, competitive-analysis, - positioning, decision-making. ---- - - - -# Industry trend strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `industry-trend-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Industry trend strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INDUSTRY}} -- {{TREND}} -- {{COMPANY}} -- {{GOAL}} - - -GOAL -Produce a high-quality deliverable for: Industry trend strategy. -Success metric: -- Produces a grounded industry + trend analysis tied to company strengths and goal. -- Proposes at least three distinct strategies with actionable steps. -- Summarizes how strategies leverage strengths to achieve the goal. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{INDUSTRY}}`, `{{TREND}}`, `{{COMPANY}}`, and `{{GOAL}}`; if critical data is missing, state assumptions explicitly. -- Provide a concise industry + trend analysis and a focused company strengths assessment. -- Propose at least 3 distinct strategies aligned to strengths and goal. -- Each strategy must include name, description, alignment, contribution to goal, challenges, and action steps. -- Keep recommendations specific and actionable, not generic. - -FORMAT -Return exactly this structure: - - -[Industry + trend analysis and company strength assessment] - - - -1. [Strategy name] - - Description: [What it is] - - Alignment: [Company strengths leveraged] - - Contribution to goal: [How it advances the goal] - - Challenges: [Risks/obstacles] - - Action steps: [Concrete steps] -2. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -3. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -[Optional additional strategies] - - - -[Summary emphasizing how strategies leverage strengths to capitalize on the trend and achieve the goal] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 strategies are provided. -- Strategies lack alignment to company strengths or contribution to goal. -- Action steps are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md b/.cursor/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md deleted file mode 100644 index 500376d5..00000000 --- a/.cursor/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-influence-strategies-from-cialdini-s-7-principles -description: >- - Influence strategies from Cialdini's 7 principles. Use when the user needs a product - workflow for stakeholder management related to influence strategies from cialdini's 7 - principles. Trigger terms: influence, cialdini, stakeholder-management. ---- - - - -# Influence strategies from Cialdini's 7 principles - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `influence-strategies-from-cialdini-s-7-principles` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Influence strategies from Cialdini's 7 principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INFLUENCE_TARGET}} -- {{INFLUENCE_GOAL}} - - -GOAL -Produce a high-quality deliverable for: Influence strategies from Cialdini's 7 principles. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate influence ideas tailored to `{{INFLUENCE_TARGET}}` and `{{INFLUENCE_GOAL}}`. -- Provide at least one specific, actionable, ethical idea for each Cialdini principle: -- Reciprocity -- Liking -- Unity -- Authority -- Social Proof -- Consistency -- Scarcity -- For each idea, include a clear strategy and rationale tied to the target context and goal. -- Use professional, non-manipulative tactics that create value for both sides. - -FORMAT -Return exactly this structure: - - - -Name of the principle -Detailed description of the strategy or tactic -Explanation of why this idea would be effective for the given target and goal - -(Repeat this structure for each of the seven principles) - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Not all seven principles are covered, or principles are duplicated while another is missing. -- Strategies are generic, unethical/manipulative, or not tied to the target and goal. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-innovation-decision-making-heuristics/SKILL.md b/.cursor/skills/productize-innovation-decision-making-heuristics/SKILL.md deleted file mode 100644 index 710886c0..00000000 --- a/.cursor/skills/productize-innovation-decision-making-heuristics/SKILL.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -name: productize-innovation-decision-making-heuristics -description: >- - Design tailored decision-making heuristics for uncertain innovation work. Use when the user - needs simple decision rules for product bets, discovery, investment, pivot, prioritization, - or opportunity selection in noisy and changing contexts. ---- - - - -# Innovation Decision Making Heuristics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovation-decision-making-heuristics` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop - -Use this skill when a team needs a practical decision rule, not a one-off recommendation. -The output should help the team decide repeatedly under uncertainty while avoiding arbitrary -or off-the-shelf rules. - -## Decision-Making Principles - -- Heuristics are useful shortcuts when the environment is noisy, dynamic, uncertain, or - time-sensitive and more information does not necessarily clarify direction. -- Heuristics fail when applied blindly, when nuance matters, or when the environment is stable - enough for more complete analysis. -- Effective heuristics should come from the user's real business challenge, constraints, - evidence, and observed feedback. -- A good heuristic makes tradeoffs explicit: speed versus accuracy, exploration versus focus, - safety versus moonshot, and learning versus commitment. -- Heuristics must be reviewed and refined through practical experience. - -## Workflow - -1. Identify the recurring decision type and the context in which it appears. -2. Classify the environment: noisy/dynamic/uncertain, stable, time-sensitive, multi-factor, - politically loaded, or high-stakes irreversible. -3. Define what the heuristic should optimize: learning, speed, risk control, focus, upside, - user value, revenue, retention, or strategic fit. -4. Identify where naive heuristics could fail. -5. Create 3-5 tailored decision rules with explicit triggers and exceptions. -6. Add a feedback loop so the rule can improve after use. - -## Output Contract - -Return: - -```markdown -# Innovation Decision Making Heuristics - -## 1. Recurring Decision -Decision type: -Who decides: -Frequency: -Time pressure: -Stakes: - -## 2. Decision Environment -Context: -Noise / uncertainty: -Information quality: -Reversibility: -Stable analysis possible: - -## 3. What The Rules Should Optimize -Primary objective: -Secondary objective: -Tradeoff to accept: -Tradeoff to avoid: - -## 4. Heuristic Failure Risks -Where shortcuts help: -Where shortcuts fail: -Bias risks: -Escalation or sunk-cost risk: - -## 5. Tailored Decision Rules -Rule 1: -Use when: -Exception: -Evidence needed: - -Rule 2: -Use when: -Exception: -Evidence needed: - -Rule 3: -Use when: -Exception: -Evidence needed: - -## 6. Feedback And Refinement -Signal to track: -Review cadence: -Who updates the rule: -When to retire the rule: -``` - -## Failure Modes - -- Provides generic principles instead of concrete decision rules. -- Creates rules that ignore the user's actual uncertainty, constraints, and feedback loops. -- Treats heuristics as always good or always bad rather than context-dependent. -- Omits exceptions and review mechanisms. diff --git a/.cursor/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md b/.cursor/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md deleted file mode 100644 index fe4b11dc..00000000 --- a/.cursor/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-project-parameters-and -description: >- - Innovative idea generation from project parameters and constraints. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, - product-management, osborn-checklist. ---- - - - -# Innovative idea generation from project parameters and constraints - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-project-parameters-and` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from project parameters and constraints**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_TYPE}} -- {{GOALS}} -- {{BUDGET}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from project parameters and constraints". -Success metric: -- Produces concrete, non-generic ideas that fit project type, goals, and budget. -- Uses structured creativity analysis (including Osborn checklist) to move beyond obvious solutions. -- Final ideas are immediately actionable with clear execution steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_TYPE}}`, `{{GOALS}}`, and `{{BUDGET}}`; if details are missing, state assumptions explicitly. -- Provide exactly 5 banal ideas to avoid and explain why each is weak. -- Define problem context including timeframe, target audience, and situation. -- Break down problem into objective, constraints, measurable success criteria, challenges, and deeper considerations. -- Analyze each chunk with explicit link to goals and budget feasibility. -- Include both creator and consumer perspectives. -- Apply Osborn checklist categories with project-relevant outputs: - - other uses, adaptations, modifications, magnification, minification, substitutions, rearrangements, reversals, combinations. -- Final ideas must be actionable for an individual, feasible under budget, and include step-by-step instructions plus application context. - -FORMAT -Return exactly this structure: - - - -1. [Banal idea] - [Why to avoid] -2. [Banal idea] - [Why to avoid] -3. [Banal idea] - [Why to avoid] -4. [Banal idea] - [Why to avoid] -5. [Banal idea] - [Why to avoid] - - - -[Clearly define the problem or situation] - - - -[Break down the problem into key aspects] - - - -[Provide in-depth analysis of each problem chunk] - - - -[Describe creator and consumer perspectives] - - - -- Other uses: [Ideas] -- Adaptations: [Ideas] -- Modifications: [Ideas] -- Magnification: [Ideas] -- Minification: [Ideas] -- Substitutions: [Ideas] -- Rearrangements: [Ideas] -- Reversals: [Ideas] -- Combinations: [Ideas] - - - -1. [Idea title] - - Specific guidance: [What to do] - - Steps: [Step-by-step] - - Where/how to apply: [Context/channel/tool] - - Budget fit: [How it stays within budget] -[Repeat for additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `banal_ideas` does not contain exactly 5 items. -- One or more Osborn checklist categories are missing. -- Final ideas are not actionable step-by-step or are not aligned to budget/goals. -- Output is generic or repeats clichรฉ ideas without meaningful differentiation. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md b/.cursor/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 3a22d36f..00000000 --- a/.cursor/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-structured-brainstorming -description: >- - Innovative idea generation from structured brainstorming techniques. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, - creativity, product-discovery, problem-solving. ---- - - - -# Innovative idea generation from structured brainstorming techniques - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from structured brainstorming techniques**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from structured brainstorming techniques". -Success metric: -- Produces a structured ideation session using free association, mind mapping, SCAMPER, and bias checks. -- Generates non-obvious, high-potential ideas grounded in the topic. -- Outputs clear top ideas with rationale and a concise synthesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run a complete structured ideation flow: - - free association (4-6 rounds), - - mind map (3-4 levels), - - SCAMPER exploration (2-3 rounds across shortlisted branches), - - bias check, - - top-idea selection and rationale. -- Avoid clichรฉd or overhyped ideas; prioritize specificity and novelty. -- Ensure top ideas are distinct from one another and clearly connected to generated branches. -- Keep outputs practical enough to be explored/prototyped next. - -FORMAT -Return exactly this structure: - - - -[4-6 rounds of free associations tied to `{{TOPIC}}`] - - - -[Mind map with 3-4 branching levels derived from free associations] - - - -1. [Branch] -2. [Branch] -3. [Branch] - - - -[2-3 rounds applying SCAMPER prompts to shortlisted branches] - - - -- Anchoring check: [Findings/adjustment] -- Status quo check: [Findings/adjustment] -- Groupthink check: [Findings/adjustment] - - - -1. [Idea 1] -2. [Idea 2] -3. [Idea 3] - - - -1. [Why idea 1 is powerful and non-obvious] -2. [Why idea 2 is powerful and non-obvious] -3. [Why idea 3 is powerful and non-obvious] - - - - -1. [Idea 1]: [Rationale] -2. [Idea 2]: [Rationale] -3. [Idea 3]: [Rationale] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `freeassociation` has fewer than 4 rounds or more than 6 rounds. -- `mindmap` does not show 3-4 levels of branching. -- `scamper` does not include at least 2 rounds. -- `top_ideas` does not contain exactly 3 distinct ideas. -- Rationales are generic and do not explain non-obvious value. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md b/.cursor/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 0ccf894a..00000000 --- a/.cursor/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -name: productize-innovative-product-ideas-from-structured-brainstorming -description: >- - Innovative product ideas from structured brainstorming. Use when the user needs a product - workflow for ideation & creativity related to innovative product ideas from structured - brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, - product-management. ---- - - - -# Innovative product ideas from structured brainstorming - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-product-ideas-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative product ideas from structured brainstorming**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative product ideas from structured brainstorming". -Success metric: -- Produces a complete structured brainstorming session from divergence to convergence. -- Generates non-obvious product ideas grounded in the topic and validated via bias checks. -- Returns exactly 3 top ideas with clear innovation rationale in abstract terms. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run all stages: free association, mind map, SCAMPER expansion, bias check, top-idea selection, summary. -- Avoid banal, overhyped, or clichรฉd outputs. -- Top ideas must be described abstractly; do not use specific tech buzzwords such as `AI`, `blockchain`, or `VR`. -- Ensure ideas are distinct and traceable to earlier brainstorming artifacts. - -FORMAT -Return exactly this structure: - - - - -1. [Word or phrase] -2. [Word or phrase] -... -[Total 8-10 items] - - - -[Topic] -- [Main branch 1] - - [Sub-branch 1a] - - [Sub-branch 1b] -- [Main branch 2] - - [Sub-branch 2a] - - [Sub-branch 2b] -- [Main branch 3] - - [Sub-branch 3a] - - [Sub-branch 3b] -[At least 3 main branches; each with 2-3 sub-branches] - - - -- Branch: [Name] - - Technique 1: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] - - Technique 2: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] -[Repeat for 3 branches] - - - -- Bias: [Name] - - Evidence in ideas: [How it appears] - - Countermeasure: [Concrete action] -[At least 1 bias] - - - -1. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -2. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -3. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] - - - -[Brief recap of process and why final ideas are stronger after SCAMPER and bias checks] - - - - -FAILURE -- Root tag `` or any required sub-tag is missing, malformed, or incomplete. -- `free_association` has fewer than 8 or more than 10 items. -- `mind_map` has fewer than 3 main branches or insufficient sub-branches. -- `scamper` does not cover 3 branches with 2 techniques each. -- `top_ideas` does not contain exactly 3 ideas. -- Top ideas include banned specific-technology terms (`AI`, `blockchain`, `VR`). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-interactive-intake-for-ost-inputs/SKILL.md b/.cursor/skills/productize-interactive-intake-for-ost-inputs/SKILL.md deleted file mode 100644 index 7353afd5..00000000 --- a/.cursor/skills/productize-interactive-intake-for-ost-inputs/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: productize-interactive-intake-for-ost-inputs -description: >- - Interactive intake for OST inputs. Use when the user needs a product workflow for user - research related to interactive intake for ost inputs. Trigger terms: user-research, ost, - continuous-discovery. ---- - - - -# Interactive intake for OST inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `interactive-intake-for-ost-inputs` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Interactive intake for OST inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Interactive intake for OST inputs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Act as an intake orchestrator for downstream OST inputs. -- Parse existing user-provided context first, then ask only missing critical questions. -- Collect and normalize exactly four variables: -- `{{business_outcome}}`: one concise, outcome-focused sentence (no solution wording). -- `{{journey_nodes_as_list}}`: JSON array of distinct journey moments (not features). -- `{{interview_transcripts_or_story_snippets}}`: markdown snippets with attribution and timestamps when available. -- `{{constraints_or_principles}}`: short markdown list/sentence or `None stated`. -- Apply quality guards: -- Reframe solution-flavored outcomes into measurable outcomes. -- Rephrase feature-like nodes into moments in time. -- Add minimal attribution labels when transcript context is sparse. -- Stop only when all four fields are present, clear, distinct, normalized, and confirmed. - -FORMAT -Return exactly this structure: - -{{business_outcome}}: [one concise, outcome-focused sentence] - -{{journey_nodes_as_list}}: ["[Moment 1]", "[Moment 2]", "[Moment 3]"] - -{{interview_transcripts_or_story_snippets}}: -[markdown transcript/snippets with speaker labels and timestamps if available] - -{{constraints_or_principles}}: -[short markdown list or sentence; if none provided, write "None stated"] - -FAILURE -- Any of the four required variables is missing or malformed. -- `{{business_outcome}}` is solution-flavored or not measurable/outcome-oriented. -- `{{journey_nodes_as_list}}` is not valid JSON array syntax or contains features instead of moments. -- Interview material lacks usable attribution/context when source data allows it. -- Constraints field is omitted instead of explicitly set to `None stated`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-lean-canvas/SKILL.md b/.cursor/skills/productize-lean-canvas/SKILL.md deleted file mode 100644 index b3a18d33..00000000 --- a/.cursor/skills/productize-lean-canvas/SKILL.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -name: productize-lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- - - - -# Lean Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `lean-canvas` -- **Lifecycle**: Think -- **Category**: Business Model -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.cursor/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md b/.cursor/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md deleted file mode 100644 index 672e4be9..00000000 --- a/.cursor/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-limit-based-product-strategy-from-problem-to-execution-plan -description: >- - Limit-based product strategy from problem to execution plan. Use when the user needs a - product workflow for product strategy related to limit-based product strategy from problem - to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, - structured-thinking. ---- - - - -# Limit-based product strategy from problem to execution plan - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `limit-based-product-strategy-from-problem-to-execution-plan` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Limit-based product strategy from problem to execution plan**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Produce a high-quality deliverable for: Limit-based product strategy from problem to execution plan. -Success metric: -- Applies the full Limit-Based Product Thinking framework end-to-end. -- Produces concrete milestones, levers, assumptions, and a phased execution plan. -- Keeps outputs grounded in the provided problem statement. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM_STATEMENT}}`; if critical details are missing, state assumptions explicitly. -- Follow all 7 framework steps in order. -- Provide quantified convergence milestones at 10%, 25%, 50%, 75%, 90% with dates or triggers. -- Identify levers to accelerate convergence and explicitly name the top 1โ€“2 highest impact moves. -- List critical assumptions with validation methods. -- Provide a 3-phase plan (Foundation, Acceleration, Optimization) with timelines and resource guidance. - -FORMAT -Return exactly this structure: - - -1. Growth Variable: [Your identified variable] - -2. Limit State Description: - [Your vivid description of the fully mature state] - -3. Core Properties of the Limit: - [List of key features and interactions] - -4. Convergence Estimate: - [Growth curve and milestones] - -5. Acceleration Strategies: - [Prioritized list of levers to steepen the curve] - -6. Critical Assumptions: - [List of assumptions with validation methods] - -7. Product Vision and Execution: - Vision Statement: [One-sentence summary] - Roadmap: [Major milestones and timelines] - 3-Phase Plan: [Brief outline of each phase] - Resource Allocation: [Key recommendations] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Convergence milestones are missing required percentages or triggers/dates. -- Acceleration strategies lack prioritized top 1โ€“2 levers. -- Assumptions lack validation methods. -- 3-phase plan is missing or not sequenced. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md b/.cursor/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md deleted file mode 100644 index 110f89a8..00000000 --- a/.cursor/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: productize-low-frequency-to-power-user-transition-strategy -description: >- - Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow - for product strategy related to low-frequency-to-power-user transition strategy. Trigger - terms: product-strategy, engagement, activation, retention. ---- - - - -# Low-Frequency-to-Power-User Transition Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `low-frequency-to-power-user-transition-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Low-Frequency-to-Power-User Transition Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_DESCRIPTION}} -- {{CURRENT_USE_CASE}} -- {{TARGET_USE_CASE}} - - -GOAL -Produce a high-quality deliverable for: Low-Frequency-to-Power-User Transition Strategy. -Success metric: -- Produces a concrete transition plan from low-frequency to high-frequency usage. -- Aligns strategy to current and target use cases with explicit behavioral gaps. -- Includes metrics, timeline, and rollout/education plans grounded in the inputs. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_DESCRIPTION}}`, `{{CURRENT_USE_CASE}}`, and `{{TARGET_USE_CASE}}`; if information is missing, state assumptions explicitly. -- Identify the behavioral gap between current and target usage. -- Provide step-by-step transition plan, education/onboarding, and communication strategy. -- Include rollout plan, key metrics, and timeline for measurement. -- Keep recommendations specific and grounded in the provided context. - -FORMAT -Return exactly this structure: - - -1. Current Use Case Analysis: - [Provide a brief analysis of the current low-frequency use case] - -2. Target Use Case Analysis: - [Provide a brief analysis of the target high-frequency use case] - -3. User Behavior and Needs: - [Summarize key insights about user behavior and needs] - -4. Transition Strategy: - a. Feature Introduction Plan: - [Outline the step-by-step plan for introducing new features] - b. User Education and Onboarding: - [Describe the approach for educating users about the new use case] - c. Communication Strategy: - [Outline the key messages and channels for communicating the benefits] - d. Gradual Rollout Plan: - [Describe the approach for gradually introducing new functionality] - -5. Implementation and Measurement: - a. Key Metrics: - [List the primary metrics to track for measuring success] - b. Timeline: - [Provide a high-level timeline for implementation and evaluation] - c. Feedback and Iteration: - [Describe the plan for collecting user feedback and making improvements] - -6. Potential Challenges and Mitigation Strategies: - [Identify potential obstacles and propose solutions] - -7. Conclusion: - [Summarize the key points of the transition strategy and its potential impact] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Behavioral gap or barriers are not explicitly identified. -- Metrics or timeline are missing. -- Strategies are generic or not tied to the given use cases. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-managerial-finance-dcf/SKILL.md b/.cursor/skills/productize-managerial-finance-dcf/SKILL.md deleted file mode 100644 index 6b191136..00000000 --- a/.cursor/skills/productize-managerial-finance-dcf/SKILL.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -name: productize-managerial-finance-dcf -description: >- - Productize Finance engine for time value of money, DCF, NPV, IRR, payback, free cash flow, - terminal value, project valuation, mutually exclusive investments, and whether growth - creates or destroys value. ---- - - - -# Managerial Finance DCF - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `managerial-finance-dcf` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings - -## Purpose - -Core investment-decision skill for evaluating projects and cash-flow streams. -Use it when comparing investments, building free cash flow forecasts, calculating -NPV/IRR/payback, estimating terminal value, or judging whether growth creates value. - -## Core Formulas - -- `FV_t = C_0 * (1 + r)^t` -- `PV = C_t / (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(C_t / (1 + r)^t)` -- `NPV with TV = -I_0 + sum(FCF_t / (1 + r)^t) + TV_N / (1 + r)^N` -- `0 = -I_0 + sum(C_t / (1 + IRR)^t)` -- `Profitability Index = PV of Future Cash Flows / Initial Investment` -- `FCF = EBIT * (1 - T_c) + Depreciation - CapEx - Delta NWC` -- `NOPAT = EBIT * (1 - T_c)` -- `TV_N = FCF_{N+1} / (r - g)` with `r > g` -- `ROIC = NOPAT / Invested Capital` -- `Reinvestment Rate = (CapEx - Depreciation + Delta NWC) / NOPAT` -- `g = ROIC * Reinvestment Rate` - -## Decision Rules - -- Independent projects: accept if `NPV > 0`; reject if `NPV < 0`. -- Mutually exclusive projects: choose the highest NPV. -- IRR supports the decision, but warn when cash flows change sign more than once, - projects differ in scale or timing, or multiple/no real IRRs exist. -- Growth creates value only when `ROIC > WACC`; it destroys value when `ROIC < WACC`. - -## Required Functions - -Use `$finance-modeling-kernel` functions for PV/FV, streams, NPV, IRR, payback, -discounted payback, annuities, perpetuities, free cash flow, terminal value, -ROIC, reinvestment rate, and sustainable growth. - -## Required Validation - -- Warn if comparing undiscounted cash flows across time. -- Warn if terminal growth exceeds long-run economic growth. -- Reject `g >= r` in growing perpetuity. -- Warn if IRR conflicts with NPV. -- Warn if payback is used as the final decision rule. -- Warn if sunk costs, financing cash flows, non-incremental overhead, cannibalization, - or opportunity cost are mishandled. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Make NPV the primary investment decision rule. diff --git a/.cursor/skills/productize-map-power-dynamics-before-meetings/SKILL.md b/.cursor/skills/productize-map-power-dynamics-before-meetings/SKILL.md deleted file mode 100644 index 6bfe5f9f..00000000 --- a/.cursor/skills/productize-map-power-dynamics-before-meetings/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-map-power-dynamics-before-meetings -description: >- - Map power dynamics before meetings. Use when the user needs a product workflow for - stakeholder management related to map power dynamics before meetings. Trigger terms: - stakeholders, power-dynamics, meetings, communication. ---- - - - -# Map power dynamics before meetings - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `map-power-dynamics-before-meetings` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Map power dynamics before meetings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DETAILS}} -- {{ATTENDEES_INFO}} - - -GOAL -Produce a high-quality deliverable for: "Map power dynamics before meetings". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{MEETING_DETAILS}}` and `{{ATTENDEES_INFO}}` to map meeting-specific power dynamics. -- Identify formal hierarchy, informal influence signals, alliances/conflicts, and each attendee's stake in outcomes. -- Rank attendees by influence in this meeting context. -- Identify decision-makers, influencers, power imbalances, and likely conflict points. -- Provide actionable strategies to navigate dynamics during the meeting. -- If information is insufficient for any claim, explicitly state the uncertainty. - -FORMAT -Return exactly this structure: - - - -[List attendees in order of influence, with brief notes on their power sources] - - - -[Bullet points of important observations about the power dynamics] - - - -[Bullet points of strategies to navigate the power dynamics effectively] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Influence ranking is not meeting-contextual or lacks power-source rationale. -- Recommendations are generic or not tied to identified dynamics/conflicts. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md b/.cursor/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md deleted file mode 100644 index 1cb24d45..00000000 --- a/.cursor/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-market-opportunities-from-jobs-to-be-done-market-canvas -description: >- - Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product - workflow for product strategy related to market opportunities from jobs-to-be-done market - canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, - product-strategy. ---- - - - -# Market opportunities from Jobs-to-be-Done market canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunities-from-jobs-to-be-done-market-canvas` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path - -Use this skill to run the Productize prompt contract for **Market opportunities from Jobs-to-be-Done market canvas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_OR_SERVICE}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Market opportunities from Jobs-to-be-Done market canvas. -Success metric: -- Guides the user through all 8 JTBD canvas steps with clear prompts. -- Keeps responses tied to provided `{{USER_INPUT}}` and the product context. -- Ends with a concise summary prompt that reflects the completed canvas. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_OR_SERVICE}}` and `{{USER_INPUT}}`; if context is missing, state assumptions explicitly. -- Ask for user input at each of the 8 JTBD canvas steps. -- Provide a brief explanation before each stepโ€™s prompt. -- Require the user to answer within the specified `` tags. -- End by requesting a `` that synthesizes the full canvas. -- Remind the user to use `{{USER_INPUT}}` when answering. - -FORMAT -Return exactly this structure: - - -[Prompt + explanation for Traditional Market Definition] - - - -[Prompt + explanation for Job Executor Determination] - - - -[Prompt + explanation for Abstracted Job Executor] - - - -[Prompt + explanation for Job Executor Documentation] - - - -[Prompt + explanation for Product Function Analysis] - - - -[Prompt + explanation for Complementary Product Analysis] - - - -[Prompt + explanation for Job Statement Abstraction] - - - -[Prompt + explanation for Final Job Documentation] - - - -[Prompt asking the user to summarize the completed canvas] - - -FAILURE -- Any required step tag in `FORMAT` is missing, malformed, or incomplete. -- Prompts do not request user responses within the correct `` tags. -- User is not reminded to use `{{USER_INPUT}}` for responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-market-opportunity/SKILL.md b/.cursor/skills/productize-market-opportunity/SKILL.md deleted file mode 100644 index bf55ae97..00000000 --- a/.cursor/skills/productize-market-opportunity/SKILL.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -name: productize-market-opportunity -description: >- - Identify, compare, and choose market opportunities for a venture, product, technology, or - innovation. Use when a founder, entrepreneur, product team, or innovator is choosing which - market to enter, picking a primary customer segment, evaluating whether a technology has - better use cases, deciding whether to pivot, comparing growth options, framing a venture for - investors, or asking variants of "which market should I target", "is this the right - opportunity", "where should I focus", "should I pivot", or "what else could this be used - for". Produces filled-in opportunity canvases for the Market Opportunity Set, Attractiveness - Map, Focus Portfolio Map, and Focus Strategy. Default to this skill when the question is - where to play rather than how to play. ---- - - - -# Market Opportunity - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunity` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market Opportunity venture brief with target segment, wedge, assumptions, and validation path - -Create the complete four-part market opportunity artifact set for choosing where a -venture, technology, product, or innovation should play. - -Use neutral terms such as `canvas`, `opportunity artifact`, `strategy surface`, or the -artifact names below. - -## Argument Hint - -`` - -## Usage - -```text -/market-opportunity $ARGUMENTS -``` - -## Required Artifacts - -For any complete request, create all four artifacts unless the user explicitly asks for -only one: - -1. **Opportunity Overview Canvas**: the three-part overview with opportunity set, - attractiveness map, and focus portfolio map. -2. **Opportunity Set Builder**: abilities -> applications -> customers -> market - opportunities. -3. **Attractiveness Evaluator**: potential and challenge ratings for each market - opportunity. -4. **Focus Portfolio Planner**: primary market opportunity, backup options, growth - options, and pursue/keep/store decisions. - -Load `references/canonical-canvases.md` before creating blank templates, filled -templates, printable layouts, or tables. It defines the exact fields and structure. - -Load `references/rating-and-decision-rules.md` before rating opportunities, -classifying map zones, or recommending primary, backup, and growth options. - -Load `references/output-formats.md` when the user asks for Markdown, HTML, PDF, -slides, visual canvases, or printable templates. - -## Workflow - -### 1. Establish the Input Mode - -Determine whether the user wants: - -- **Blank canvas set**: empty structured artifacts for a team to fill in. -- **Filled canvas set**: completed artifacts from a venture/product/technology idea. -- **Opportunity review**: critique or improve an existing opportunity set. -- **Strategy decision**: choose the primary opportunity and portfolio options. -- **Printable artifact**: create visual HTML/PDF/slide-ready canvases. - -If context is missing, ask only for the smallest useful missing piece: - -- The venture, product, technology, or core ability. -- Candidate applications. -- Candidate customer groups. -- Existing evidence for demand, market size, economics, implementation, timing, and risks. - -### 2. Generate the Market Opportunity Set - -Identify the venture's core abilities or technological elements first. Describe them -independent of the envisioned product. - -Then generate combinations: - -```text -market opportunity = application + customer segment -``` - -Segment customers precisely. Avoid broad labels like "enterprises" or "consumers" -unless the user has no better information. - -### 3. Evaluate Attractiveness - -For each market opportunity, rate: - -- **Potential** - - Compelling reason to buy. - - Market volume. - - Economic viability. -- **Challenge** - - Implementation obstacles. - - Time to revenue. - - External risks. - -Use the four-level rating scale: - -```text -Low / Mid / High / Super High -``` - -Then place each opportunity on the attractiveness map: - -- **Gold Mine** -- **Quick Win** -- **Moon Shot** -- **Questionable** - -### 4. Design the Focus Portfolio - -Choose one **Primary Market Opportunity** based on attractiveness and strategic fit. - -For other attractive opportunities, assess relatedness to the primary opportunity: - -- **Product relatedness**: shared technological competences, required resources, - and necessary networks. -- **Market relatedness**: shared customer values and benefits, sales channels, and - word-of-mouth paths. - -Classify each option: - -- **Growth Option**: attractive and useful for creating additional value. -- **Backup Option**: attractive and does not share major risks with the primary path. -- **Storage**: documented but not worth active preservation now. - -Make one of three action decisions for each option: - -- Pursue now. -- Keep open. -- Place in storage. - -The final strategy must keep at least one credible backup option and one credible -growth option open unless the available evidence makes that impossible. If impossible, -say what evidence or opportunity generation is missing. - -### 5. Tie Strategy to Execution - -For completed strategy outputs, include implications for: - -- Product and technology modularity. -- IP and defensibility. -- Hiring and capability development. -- Stakeholder and investor alignment. -- Brand and market communication. -- Experiments, assumptions, and learning loops. -- Business Model Canvas, Value Proposition Canvas, and Lean Startup integration when - the user asks for execution planning. - -## Output Rules - -- Preserve the canonical field names and rating scales from the reference files. -- Do not collapse the framework into SWOT, generic market sizing, or a feature - prioritization matrix. -- Be explicit about assumptions and evidence gaps. -- Use tables for editable outputs. -- For visual outputs, use the same four-artifact structure and neutral artifact titles. -- Do not copy long passages from source PDFs. Use the exact operational labels and - schemas, with original wording for explanations and recommendations. diff --git a/.cursor/skills/productize-market-opportunity/references/canonical-canvases.md b/.cursor/skills/productize-market-opportunity/references/canonical-canvases.md deleted file mode 100644 index a3c436db..00000000 --- a/.cursor/skills/productize-market-opportunity/references/canonical-canvases.md +++ /dev/null @@ -1,234 +0,0 @@ -# Canonical Market Opportunity Canvases - -Use these four canvases as the canonical output surfaces. Use neutral artifact names in -user-facing output. - -## 1. Opportunity Overview Canvas - -Purpose: show the entire flow from opportunity generation to attractiveness placement -to focus portfolio decision. - -Required fields: - -- Name. -- Date. -- Title: `Market Opportunity Overview`. -- Market opportunity definition: `application + customer`. -- Left panel: **Market Opportunity Set**. -- Middle panel: **Attractiveness Map**. -- Right panel: **Focus Portfolio Map**. - -### Market Opportunity Set Panel - -Contains market opportunity cards generated from: - -```text -application + customer = market opportunity -``` - -Each card should have: - -| Field | Description | -|---|---| -| ID | Short stable label such as MO-1, MO-2, MO-3 | -| Application | What the core ability enables | -| Customer segment | Who needs that application | -| Market opportunity | Combined application + customer | - -### Attractiveness Map Panel - -Axes: - -| Axis | Direction | Rating Levels | -|---|---|---| -| Potential | vertical | Low, Mid, High, Super High | -| Challenge | horizontal | Low, Mid, High, Super High | - -Zones: - -| Zone | Meaning | -|---|---| -| Gold Mine | High potential with relatively low challenge | -| Quick Win | Lower potential with relatively low challenge | -| Moon Shot | High potential with high challenge | -| Questionable | Lower potential with high challenge | - -### Focus Portfolio Map Panel - -Nested decision areas: - -| Area | Meaning | -|---|---| -| Pursue now | Active focus or active parallel pursuit | -| Keep open | Preserve option value without fully committing | -| Place in storage | Document but do not actively preserve now | - -Cards placed here must identify whether they are primary, backup, growth, or storage -options. - -## 2. Opportunity Set Builder - -Purpose: generate market opportunities by combining core abilities, applications, and -customer segments. - -Required fields: - -- Name. -- Date. -- Title: `Generate Your Market Opportunity Set`. -- Core abilities or technological elements. -- Applications. -- Customers. -- Market opportunities. - -### Core Abilities Table - -List the venture's core abilities or technological elements. Characterize each by -function and properties, independent from the envisioned product. - -| Ability ID | Core Ability or Technological Element | Function | Key Properties | Evidence / Notes | -|---|---|---|---|---| -| A1 | | | | | -| A2 | | | | | -| A3 | | | | | -| A4 | | | | | - -### Market Opportunity Generation Table - -Use each row to combine an application with a customer segment. - -| Opportunity ID | Ability ID(s) | Application | Customer Segment | Finer Customer Segmentation | Market Opportunity | -|---|---|---|---|---|---| -| MO-1 | | | | | | -| MO-2 | | | | | | -| MO-3 | | | | | | - -Generation prompts: - -- Which applications can the core abilities offer? -- Which customers may need each application? -- Can the customer group be segmented more precisely? -- Which combinations should be evaluated next? - -## 3. Attractiveness Evaluator - -Purpose: evaluate each market opportunity by potential and challenge, then place it -on the attractiveness map. - -Required fields: - -- Name. -- Date. -- Title: `Evaluate Market Opportunity Attractiveness`. -- Market Opportunity. -- Potential. -- Challenge. -- Overall Potential. -- Overall Challenge. -- Attractiveness Map zone. - -Use this canvas once for every market opportunity being evaluated. - -### Potential Ratings - -| Potential Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Compelling Reason to Buy | Unmet need; effective solution; better than current solutions | Low / Mid / High / Super High | | -| Market Volume | Current market size; expected growth | Low / Mid / High / Super High | | -| Economic Viability | Margins (value vs. cost); customers' ability to pay; customer stickiness | Low / Mid / High / Super High | | - -### Challenge Ratings - -| Challenge Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Implementation Obstacles | Product development difficulties; sales and distribution difficulties; funding challenges | Low / Mid / High / Super High | | -| Time to Revenue | Development time; time between product and market readiness; length of sales cycle | Low / Mid / High / Super High | | -| External Risks | Competitive threat; third-party dependencies; barriers to adoption | Low / Mid / High / Super High | | - -### Overall Placement - -| Market Opportunity | Overall Potential | Overall Challenge | Map Zone | Rationale | -|---|---|---|---|---| -| | Low / Mid / High / Super High | Low / Mid / High / Super High | Gold Mine / Quick Win / Moon Shot / Questionable | | - -## 4. Focus Portfolio Planner - -Purpose: design the focus strategy around one primary market opportunity while -preserving backup and growth options. - -Required fields: - -- Name. -- Date. -- Title: `Design Your Focus Strategy`. -- Primary Market Opportunity. -- Other attractive market opportunities. -- Product relatedness. -- Market relatedness. -- Suitable as backup option. -- Suitable as growth option. -- Action decision: pursue now, keep open, or place in storage. - -### Step I: Choose Primary Market Opportunity - -Choose the primary market opportunity based on the attractiveness map. - -| Primary Market Opportunity | Attractiveness Map Position | Why This Is Primary | Main Evidence | Main Risks | -|---|---|---|---|---| -| | | | | | - -### Step II: Examine Other Attractive Opportunities - -For each other attractive market opportunity, compare it with the primary opportunity. - -| Option ID | Market Opportunity | Product Relatedness | Product Relatedness Rationale | Market Relatedness | Market Relatedness Rationale | Risk Overlap With Primary | -|---|---|---|---|---|---|---| -| MO-2 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-3 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-4 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | - -Product relatedness asks how much the products share: - -- Technological competences. -- Required resources. -- Necessary networks. - -Market relatedness asks how much the customers share: - -- Values and benefits. -- Sales channels. -- Word-of-mouth paths. - -### Step III: Classify and Decide - -Use this table to mark whether each option is suitable as backup, growth, both, or -neither, then decide what to do with it. - -| Option ID | Market Opportunity | Backup Option? | Growth Option? | Action | Rationale | -|---|---|---|---|---|---| -| MO-2 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-3 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-4 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | - -Definitions: - -- **Backup Option**: an attractive market opportunity that does not share major risks - with the primary market opportunity and can support a change in direction. -- **Growth Option**: an attractive market opportunity that can create additional value - if the primary opportunity succeeds. - -Strategy rule: - -- Keep at least one Backup Option open. -- Keep at least one Growth Option open. -- Decide whether any option is worth pursuing now. -- Place the rest in storage. - -### Final Focus Strategy Summary - -| Category | Market Opportunity | Decision | Why | -|---|---|---|---| -| Primary | | Pursue now | | -| Backup | | Keep open / Pursue now | | -| Growth | | Keep open / Pursue now | | -| Storage | | Place in storage | | diff --git a/.cursor/skills/productize-market-opportunity/references/output-formats.md b/.cursor/skills/productize-market-opportunity/references/output-formats.md deleted file mode 100644 index ee145a61..00000000 --- a/.cursor/skills/productize-market-opportunity/references/output-formats.md +++ /dev/null @@ -1,143 +0,0 @@ -# Output Formats - -Use the same canonical four-artifact structure in every format. Use neutral artifact -names in titles and headings. - -## Markdown Blank Canvas Set - -Use when the user wants editable text tables. - -Required sections: - -```markdown -# Market Opportunity - -## 1. Opportunity Overview Canvas -[overview tables] - -## 2. Opportunity Set Builder -[blank abilities and opportunity generation tables] - -## 3. Attractiveness Evaluator -[one blank evaluator per opportunity, or reusable blank evaluator] - -## 4. Focus Portfolio Planner -[blank primary, relatedness, backup/growth, and action decision tables] -``` - -## Markdown Filled Canvas Set - -Use when the user provides a venture, technology, product, or opportunity set. - -Required sections: - -```markdown -# Market Opportunity: [Venture/Product] - -## 1. Opportunity Overview Canvas -- Market opportunity cards. -- Attractiveness placements. -- Focus portfolio decisions. - -## 2. Opportunity Set Builder -- Core abilities. -- Applications. -- Customer segments. -- Generated market opportunities. - -## 3. Attractiveness Evaluator -- One evaluation table per selected market opportunity. -- Overall potential, overall challenge, and map zone. - -## 4. Focus Portfolio Planner -- Primary market opportunity. -- Option comparison by product and market relatedness. -- Backup/growth classification. -- Pursue now / keep open / place in storage decisions. - -## Strategy Implications -- Product/technology modularity. -- IP and defensibility. -- Hiring/capability needs. -- Stakeholder and investor alignment. -- Brand and communication implications. -- Experiments and next evidence to collect. -``` - -## Visual or Printable Canvas - -Use when the user asks for printable templates, visual canvases, an HTML file, a PDF, -or a slide-ready output. - -Requirements: - -- Produce four separate pages or sections. -- Preserve the same layout logic: - - Overview: three panels side by side. - - Opportunity Set Builder: abilities at top; applications and customers below. - - Attractiveness Evaluator: potential on left, challenge on right, overall ratings at - the bottom. - - Focus Portfolio Planner: primary opportunity at top, option columns below, relatedness - rows, backup/growth rows, action rows at bottom. -- Use neutral artifact titles. -- Include `Name` and `Date` fields when producing a printable artifact. -- Include editable blank spaces or filled content depending on the requested mode. - -Recommended visual names: - -| Original Function | Use This Title | -|---|---| -| Full opportunity overview | Market Opportunity Overview | -| Generate opportunity set | Opportunity Set Builder | -| Evaluate attractiveness | Market Opportunity Attractiveness | -| Design focus strategy | Focus Strategy Planner | - -## Compact Decision Memo - -Use when the user wants a concise strategic answer rather than the full canvas set. - -Required sections: - -```markdown -## Recommendation -[Primary market opportunity and why] - -## Opportunity Portfolio -| Category | Opportunity | Decision | Why | - -## Key Ratings -| Opportunity | Potential | Challenge | Zone | - -## Risks and Open Assumptions -[Most important evidence gaps] - -## Next Tests -[Lean experiments or research needed] -``` - -## Spreadsheet-Friendly Format - -Use when the user wants to paste into Sheets/Excel. - -Create four CSV-style tables: - -1. `opportunity_set` -2. `attractiveness_ratings` -3. `map_placements` -4. `focus_portfolio` - -Minimum columns: - -```text -opportunity_set: -opportunity_id,ability_ids,application,customer_segment,finer_segment,market_opportunity - -attractiveness_ratings: -opportunity_id,potential_compelling_reason,potential_market_volume,potential_economic_viability,overall_potential,challenge_implementation,challenge_time_to_revenue,challenge_external_risks,overall_challenge,evidence_notes - -map_placements: -opportunity_id,overall_potential,overall_challenge,map_zone - -focus_portfolio: -opportunity_id,role,product_relatedness,market_relatedness,risk_overlap,backup_option,growth_option,action,rationale -``` diff --git a/.cursor/skills/productize-market-opportunity/references/rating-and-decision-rules.md b/.cursor/skills/productize-market-opportunity/references/rating-and-decision-rules.md deleted file mode 100644 index fdfe3093..00000000 --- a/.cursor/skills/productize-market-opportunity/references/rating-and-decision-rules.md +++ /dev/null @@ -1,250 +0,0 @@ -# Rating and Decision Rules - -Use these rules to keep opportunity ratings consistent. - -## Rating Scale - -Use only these four levels: - -```text -Low / Mid / High / Super High -``` - -For challenge dimensions, higher means more difficult, slower, riskier, or more -resource-intensive. Low challenge is good. - -## Potential Ratings - -### Compelling Reason to Buy - -Rate based on: - -- Strength of unmet need. -- Whether the solution effectively addresses the need. -- Whether it is better than current alternatives. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak pain, unclear need, or little advantage over alternatives | -| Mid | Recognizable need but limited urgency or differentiation | -| High | Clear need, strong solution fit, meaningful advantage | -| Super High | Urgent need, strong willingness to switch or buy, clear superiority | - -### Market Volume - -Rate based on: - -- Current market size. -- Expected growth. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Small or shrinking reachable market | -| Mid | Meaningful niche or uncertain growth | -| High | Large reachable market or strong growth | -| Super High | Very large market with strong growth and credible reach | - -### Economic Viability - -Rate based on: - -- Margins: value created versus cost to deliver. -- Customers' ability to pay. -- Customer stickiness. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak margins, low willingness or ability to pay, low retention potential | -| Mid | Economics may work but are not yet proven | -| High | Attractive value/cost relationship and credible willingness to pay | -| Super High | Strong margins, high willingness to pay, strong retention or lock-in | - -## Challenge Ratings - -### Implementation Obstacles - -Rate based on: - -- Product development difficulties. -- Sales and distribution difficulties. -- Funding challenges. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Straightforward product, go-to-market, and funding path | -| Mid | Some execution difficulty, but manageable | -| High | Significant product, distribution, or funding obstacles | -| Super High | Very difficult execution path or major resource gap | - -### Time to Revenue - -Rate based on: - -- Development time. -- Gap between product readiness and market readiness. -- Length of sales cycle. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Revenue can plausibly arrive quickly | -| Mid | Moderate path to revenue | -| High | Long development, readiness, or sales cycle | -| Super High | Very long or uncertain time to revenue | - -### External Risks - -Rate based on: - -- Competitive threat. -- Third-party dependencies. -- Barriers to adoption. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Limited external risk or manageable dependencies | -| Mid | Some competitive, dependency, or adoption risk | -| High | Serious external risks that could block progress | -| Super High | External risks may dominate the opportunity | - -## Overall Potential and Challenge - -Do not compute mechanically unless the user asks for numeric scoring. Use evidence and -judgment. - -Default aggregation: - -- Overall Potential should reflect the weakest critical potential dimension. A huge - market is not enough if there is no compelling reason to buy. -- Overall Challenge should reflect the hardest blocking challenge. A simple build is - not enough if revenue requires a multi-year sales cycle. - -If using numeric support: - -```text -Low = 1 -Mid = 2 -High = 3 -Super High = 4 -``` - -Use the rounded average as a starting point, then adjust for blockers and explain the -adjustment. - -## Attractiveness Map Zone Rules - -| Overall Potential | Overall Challenge | Zone | -|---|---|---| -| High or Super High | Low or Mid | Gold Mine | -| Low or Mid | Low or Mid | Quick Win | -| High or Super High | High or Super High | Moon Shot | -| Low or Mid | High or Super High | Questionable | - -Interpretation: - -- **Gold Mine**: strongest candidate for primary focus. -- **Quick Win**: potentially useful for learning, early traction, or stepping stones. -- **Moon Shot**: valuable but difficult; may require capital, patience, or unique assets. -- **Questionable**: weak candidate unless strategic reasons or new evidence change the view. - -## Primary Market Opportunity Rules - -Select the primary opportunity by weighing: - -- Attractiveness map zone. -- Strength of evidence. -- Founder/team fit. -- Ability to test assumptions. -- Strategic control and defensibility. -- Fit with resource constraints. - -Default preference: - -1. Gold Mine with strong evidence. -2. Gold Mine with evidence gaps but testable assumptions. -3. Quick Win if it creates learning, revenue, or capability for a larger path. -4. Moon Shot only if the upside is large enough and the team has unusual advantages. -5. Questionable only if the user explicitly has strategic reasons. - -## Backup Option Rules - -A backup option should be attractive and should not share major risks with the primary -opportunity. - -Good backup options often differ on: - -- Customer segment. -- Sales channel. -- Adoption barrier. -- Regulatory pathway. -- Revenue model. -- Critical dependency. - -Do not label an option as backup merely because it is related. If it fails for the same -reason the primary fails, it is not a useful backup. - -## Growth Option Rules - -A growth option should be attractive and should let the venture create additional value -after or alongside the primary opportunity. - -Good growth options often share: - -- Technology. -- Capabilities. -- Customer relationships. -- Distribution. -- Brand credibility. -- Data or network effects. - -High relatedness makes a growth option more plausible. Very low relatedness usually -means the opportunity is diversification, not a near-term growth option. - -## Action Decision Rules - -### Pursue Now - -Use when: - -- The option is primary, or -- The option is highly attractive, resources permit parallel pursuit, and pursuing it - does not dilute the primary focus. - -### Keep Open - -Use when: - -- The option has strategic value as backup or growth. -- The cost of preserving it is modest. -- It requires monitoring, lightweight experiments, modular design choices, IP claims, - partner conversations, or relationship maintenance. - -### Place in Storage - -Use when: - -- The option is not attractive enough now. -- The opportunity is too unrelated or costly to preserve. -- Evidence is too weak. -- It is worth remembering but not worth spending active effort on. - -## Evidence Discipline - -For each rating, distinguish: - -- Evidence: facts, interviews, data, observed behavior, signed interest, market numbers. -- Assumptions: plausible but unvalidated beliefs. -- Unknowns: missing information that could change the rating. - -When evidence is weak, phrase the output as a hypothesis and propose the next test. diff --git a/.cursor/skills/productize-market-orientation-audit/SKILL.md b/.cursor/skills/productize-market-orientation-audit/SKILL.md deleted file mode 100644 index 914f16eb..00000000 --- a/.cursor/skills/productize-market-orientation-audit/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: productize-market-orientation-audit -description: >- - Audit whether an organization is truly market oriented using intelligence generation, - intelligence dissemination, and responsiveness. Use for customer-centricity, marketing - culture, organizational diagnosis, market sensing, and scorecard-based improvement plans. ---- - - - -# Market Orientation Audit - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-orientation-audit` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user wants to diagnose how well an organization senses markets, shares customer/competitor insight internally, and acts on that insight. - -Do not use it for brand health, campaign evaluation, or product-market fit unless the question is specifically about organizational market orientation. - -## Core Model - -Market orientation is an organization-wide culture and operating system for creating customer value. It has three dimensions: - -- **Intelligence generation**: how the organization detects customer, competitor, collaborator, technology, and regulatory changes. -- **Intelligence dissemination**: how quickly and effectively insight spreads across functions. -- **Responsiveness**: how fast and well the organization acts on market intelligence. - -## Scorecard - -Use a 1-5 scale: - -- 5 = Strongly agree -- 4 = Agree -- 3 = Neither agree nor disagree -- 2 = Disagree -- 1 = Strongly disagree - -Each dimension has 8 items. Dimension scoring: - -- 29-40 = High -- 20-28 = Moderate -- 8-19 = Low - -Total scoring: - -- 86-120 = High -- 60-85 = Moderate -- 24-59 = Low - -### Intelligence Generation - -1. We have interdepartmental meetings at least once a quarter to discuss market trends and developments. -2. We are quick to detect fundamental shifts in our industry, such as competition, technology, or regulation. -3. We periodically review the likely effect of environmental changes on customers. -4. We are fast to detect changes in customer product and service preferences. -5. People discuss customers' future needs with other functions or departments. -6. We do a lot of in-house market research. -7. We survey key customers at least once a year to assess product and service quality. -8. We meet key clients at least once a year to learn what products or services they will need in the future. - -### Intelligence Dissemination - -1. When something important happens to a major customer or market, the whole business knows quickly. -2. When one department learns something important about competitors, it quickly alerts other departments. -3. We would never ignore changes in customer product or service needs. -4. When customers want a product or service modification, involved teams make concerted efforts to respond. -5. We periodically review product or service development to ensure it aligns with key customer needs. -6. We have communication systems that speed dissemination of important customer-related information. -7. All functions and departments are responsive to each other's needs and requests. -8. When a customer complains or gives feedback, we quickly share it with anyone who can act on it. - -### Responsiveness - -1. It takes very little time to decide how to respond to competitor product or service changes. -2. We can implement new ideas, marketing plans, product redesigns, or service enhancements in a timely fashion. -3. Several functions periodically plan responses to changes in the business environment. -4. If a major competitor aggressively targeted a key customer, we would consider a response immediately. -5. We quickly act on customer complaints and feedback. -6. Customer-facing employees have latitude to solve customer problems without excessive red tape. -7. People here tend to talk more about opportunities than problems. -8. When we see a new opportunity to create customer value, we act quickly. - -## Workflow - -1. Collect scores from the user or run a facilitated self-assessment. -2. Compute dimension totals and total score. -3. Identify the weakest dimension and the lowest individual items. -4. Diagnose root causes across incentives, structure, tooling, decision rights, data access, rituals, and culture. -5. Translate findings into operating changes, not just research recommendations. -6. Define a 30/60/90-day improvement plan and measurement cadence. - -## Output - -Return: - -- **Score Summary**: dimension scores, total score, high/moderate/low rating. -- **Pattern Diagnosis**: what the scores imply about market sensing, sharing, and action. -- **Lowest Items**: the specific behaviors causing the largest gap. -- **Organizational Hurdles**: structure, incentives, data, rituals, authority, culture. -- **Improvement Plan**: 30/60/90-day actions. -- **Operating Metrics**: indicators to track improvement. - -## Quality Bar - -- Do not equate customer-facing friendliness with market orientation. -- Treat market orientation as cross-functional. -- Separate collecting insight from acting on insight. -- Recommend concrete operating changes, not generic "talk to customers more" advice. diff --git a/.cursor/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md b/.cursor/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md deleted file mode 100644 index ca888dbb..00000000 --- a/.cursor/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: productize-market-requirements-from-strategic-market-inputs -description: >- - Market requirements from strategic market inputs. Use when the user needs a product workflow - for product strategy related to market requirements from strategic market inputs. Trigger - terms: product-management, market-research, strategy, MRD. ---- - - - -# Market requirements from strategic market inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-requirements-from-strategic-market-inputs` -- **Lifecycle**: Strategize -- **Category**: Discovery -- **Primary artifact**: Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Market requirements from strategic market inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MARKET_INDUSTRY}} -- {{PROBLEM_UNMET_NEED}} -- {{TARGET_USER_BUYER}} -- {{CURRENT_ALTERNATIVES}} -- {{COMPANY_ROLE_VISION_ADVANTAGE}} -- {{EXTERNAL_FACTORS}} -- {{OUTPUT_REQUEST}} - - -GOAL -Produce a high-quality deliverable for: Market requirements from strategic market inputs. -Success metric: -- Gathers required MRD inputs via a structured question flow. -- Produces decision-ready MRD sections only after the user confirms โ€œReady to draft.โ€ -- Keeps analysis concise, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; ask one question at a time until the user says **โ€œReady to draft.โ€** -- Do not draft any MRD section before the user explicitly says **โ€œReady to draft.โ€** -- After the user selects the output (Aโ€“D), produce that section only and pause for feedback. -- Use links for citations; state assumptions explicitly. -- No emojis. No JSON output. - -FORMAT -Return exactly this structure: - - -Letโ€™s co-create a Market Requirements Document. Iโ€™ll ask a few questions to gather context and then generate a draft. First up: What market or industry are you exploring? - - - -[Your single next question based on the most recent answer] - - -[When user says โ€œReady to draft,โ€ respond with exactly one of the requested MRD sections using the MRD Output Format headings.] - -FAILURE -- Output drafts MRD sections before user says โ€œReady to draft.โ€ -- More than one question is asked at a time. -- Output does not follow the selected section from Aโ€“D. -- Missing citations/assumptions where needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-market-sizing/SKILL.md b/.cursor/skills/productize-market-sizing/SKILL.md deleted file mode 100644 index 6467fec0..00000000 --- a/.cursor/skills/productize-market-sizing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, - market-entry upside, or investor-ready opportunity size. ---- - - - -# Market Sizing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-sizing` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.cursor/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md b/.cursor/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md deleted file mode 100644 index be955241..00000000 --- a/.cursor/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: productize-mece-analysis-and-logical-tree-from-list-items -description: >- - MECE analysis and logical tree from list items. Use when the user needs a product workflow - for decision making related to mece analysis and logical tree from list items. Trigger - terms: pm, decision-making, mece, structured-thinking, frameworks. ---- - - - -# MECE analysis and logical tree from list items - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `mece-analysis-and-logical-tree-from-list-items` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **MECE analysis and logical tree from list items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{LIST_OF_ITEMS}} - - -GOAL -Evaluate `LIST_OF_ITEMS` for MECE quality and produce a logical tree that resolves overlaps/gaps. -Success metric: -- Clearly assesses mutual exclusivity and collective exhaustiveness. -- Identifies concrete overlaps and coverage gaps (if any). -- Produces a coherent tree structure reflecting corrected grouping logic. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Test pairwise overlap (mutual exclusivity). - 2. Test coverage gaps (collective exhaustiveness). - 3. Propose corrected structure and hierarchy. -- Keep conclusions grounded in the provided list; avoid unrelated frameworks unless necessary. -- If ambiguity exists in item definitions, state assumptions explicitly. -- Provide concise rationale, not hidden/internal chain-of-thought. - -FORMAT -Return exactly this structure: - - - -[State whether items are mutually exclusive, with specific overlap examples where relevant] - - -[State whether items are collectively exhaustive, with specific gap examples where relevant] - - -[Concise list of overlap issues and/or coverage gaps] - - - - -[MECE status: Fully MECE | Not MECE | Partially MECE] - -[Hierarchical tree showing corrected structure and item placement] - - - -FAILURE -- Required schema sections are missing or malformed. -- Mutual exclusivity or collective exhaustiveness assessment is absent. -- Logical tree is missing, unclear, or inconsistent with analysis findings. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md b/.cursor/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md deleted file mode 100644 index 917e0acf..00000000 --- a/.cursor/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: productize-meeting-agendas-from-meeting-descriptions -description: >- - Meeting agendas from meeting descriptions. Use when the user needs a product workflow for - project management related to meeting agendas from meeting descriptions. Trigger terms: - meetings, facilitation, planning, productivity. ---- - - - -# Meeting agendas from meeting descriptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-agendas-from-meeting-descriptions` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Meeting agendas from meeting descriptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DESCRIPTION}} - - -GOAL -Produce a high-quality deliverable for: "Meeting agendas from meeting descriptions". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a meeting preparation output from `{{MEETING_DESCRIPTION}}` that includes: -- A clear purpose statement for the meeting. -- A structured agenda with allocated time per topic and key questions per topic. -- A practical process/flow for running the meeting to achieve the stated purpose. -- Internally reason from meeting goals, stakeholders, and constraints; return only the required final sections. - -FORMAT -Return exactly this structure: - - -[Clear and concise purpose statement] - - - -1. [Agenda Topic 1] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -2. [Agenda Topic 2] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -[Additional agenda topics] - - - -[Suggested process and flow for the meeting] - - -FAILURE -- Any required section (``, ``, ``) is missing or materially incomplete. -- Agenda items do not include both time allocation and key questions. -- Meeting flow/process is generic and not tied to the stated purpose. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md b/.cursor/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md deleted file mode 100644 index bbf05acf..00000000 --- a/.cursor/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: productize-meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- - - - -# Meeting Outcome Planning and Stakeholder Alignment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-outcome-planning-and-stakeholder-alignment` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md b/.cursor/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md deleted file mode 100644 index 60997def..00000000 --- a/.cursor/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-meeting-summaries-from-meeting-transcript-ideas-framework -description: >- - Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a - product workflow for presentation & communication related to meeting summaries from meeting - transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, - note-taking. ---- - - - -# Meeting summaries from meeting transcript (IDEAS framework) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-summaries-from-meeting-transcript-ideas-framework` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Meeting summaries from meeting transcript (IDEAS framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Meeting summaries from meeting transcript (IDEAS framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are tasked with summarizing a meeting using the IDEAS framework. This framework helps organize the key points of a meeting into five categories: Insights, Decisions, Engagements, Actions, and Summary. Here's the meeting transcript you need to analyze: - - -{{MEETING_TRANSCRIPT}} - - -Please carefully read and analyze the meeting transcript. Then, summarize the meeting using the IDEAS framework as follows: - -1. Insights: Identify and list the main insights or important realizations that emerged during the meeting. -2. Decisions: Note any decisions that were made during the meeting. -3. Engagements: List any tasks or responsibilities that were assigned to specific individuals or teams. -4. Actions: Highlight any immediate actions that need to be taken as a result of the meeting. -5. Summary: Provide a brief overall summary of the meeting's impact and significance. - -When writing your summary, please be concise and focused. Aim to capture the most important points rather than trying to include every detail. Use bullet points for each category to make the summary easy to read and understand. - -Present your summary using the following format, enclosed in XML tags: - -Remember to focus on the most significant and relevant information for each category. Your goal is to provide a clear, organized, and useful summary of the meeting using the IDEAS framework. - - -FORMAT -Return exactly this structure: - - - -โ€ข [List insights here] - - - -โ€ข [List decisions here] - - - -โ€ข [List engagements here] - - - -โ€ข [List actions here] - - - -[Write a brief overall summary here] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-message-framing-and-comms-plan-designer/SKILL.md b/.cursor/skills/productize-message-framing-and-comms-plan-designer/SKILL.md deleted file mode 100644 index 8cc37534..00000000 --- a/.cursor/skills/productize-message-framing-and-comms-plan-designer/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-message-framing-and-comms-plan-designer -description: >- - Message Framing & Comms Plan Designer. Use when the user needs a product workflow for - stakeholder management related to message framing & comms plan designer. Trigger terms: - communication, executive-communication, messaging, stakeholder-management. ---- - - - -# Message Framing & Comms Plan Designer - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `message-framing-and-comms-plan-designer` -- **Lifecycle**: Design -- **Category**: Marketing -- **Primary artifact**: Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Message Framing & Comms Plan Designer**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Message Framing & Comms Plan Designer. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use provided facts, audience, goal, and writing sample to design a message framing and communication plan. -- Provide 2-3 viable framing options, each with a one-line rationale tied to credibility, logic, and audience emotion. -- Produce two concise drafts in the user's natural tone: -- `ICs` draft with context, changes, actions, and timeline (`<=180` words). -- `Execs` draft with BLUF, risks/asks, and decision needed (`<=120` words). -- Include a strong subject/headline and two Slack snippets (announcement + reminder). -- Provide a mini comms plan with channel sequence, owner, timing, emphasis, and CTA. -- Include a `What to Omit` noise-reduction list and exactly 3 success signals. - -FORMAT -Return exactly this structure: - -Frames & Rationale -- [Frame 1]: [one-line rationale] -- [Frame 2]: [one-line rationale] -- [Frame 3 if used]: [one-line rationale] - -Draft for ICs -Subject/Headline: [text] -[ICs draft <=180 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Draft for Execs -Subject/Headline: [text] -[Execs draft <=120 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Mini Comms Plan -| Step | Channel | Owner | Timing | Emphasis | CTA | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -What to Omit -- [item] - -Success Signals -1. [signal] -2. [signal] -3. [signal] - -FAILURE -- Any required section is missing or materially incomplete. -- ICs draft exceeds 180 words or Execs draft exceeds 120 words. -- Missing subject/headline or missing either Slack snippet type (announcement/reminder). -- Comms plan table is missing required columns or sequence logic. -- Success Signals are not exactly three measurable indicators. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.cursor/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md b/.cursor/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md deleted file mode 100644 index 364641cd..00000000 --- a/.cursor/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- - - - -# Metric drops diagnosis with rigorous stepwise decomposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- **Lifecycle**: Strategize -- **Category**: Analytics -- **Primary artifact**: Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/.cursor/skills/productize-metrics-review/SKILL.md b/.cursor/skills/productize-metrics-review/SKILL.md deleted file mode 100644 index ce1527cf..00000000 --- a/.cursor/skills/productize-metrics-review/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-metrics-review -description: >- - Review and analyze product metrics with trend analysis and actionable insights. Use when - running a weekly, monthly, or quarterly metrics review, investigating a spike or drop, - comparing against targets, or turning raw numbers into a scorecard with recommended actions. ---- - - - -# Metrics Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metrics-review` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Metric scorecard, trend diagnosis, and recommended action plan - -Review product metrics, identify trends, and surface action-oriented insights. - -## Argument Hint - -`
` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/.factory/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md b/.factory/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md deleted file mode 100644 index 58de7bfa..00000000 --- a/.factory/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: productize-feature-impact-models-from-kpis-and-assumptions -description: >- - Feature impact models from KPIs and assumptions. Use when the user needs a product workflow - for business analysis related to feature impact models from kpis and assumptions. Trigger - terms: pm, business-analysis, financial-modeling, kpi-impact. ---- - - - -# Feature impact models from KPIs and assumptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-impact-models-from-kpis-and-assumptions` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Feature impact models from KPIs and assumptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_INFO}} -- {{KPIS_TO_ESTIMATE}} - - -GOAL -Produce a high-quality deliverable for: Feature impact models from KPIs and assumptions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Build a procedural task list that covers: - - key assumptions, - - baseline metric calculations, - - per-KPI impact estimation, - - sensitivity analysis. -- Execute the tasks and show calculations step by step using explicit formulas/equations. -- For each KPI, provide: - - point estimate, - - assumptions and calculations used, - - brief explanation of feature-to-KPI impact mechanism. -- If information is missing, state what is missing, add a reasonable assumption, label it clearly, and proceed. -- Prioritize transparent math and reasoning over spreadsheet-like verbosity. -- Keep conclusions focused on executive decision-making (investment impact, major drivers, key risks). - - -FORMAT -Return exactly this structure: - - - -[List the procedural tasks used to build the model] - - - -[Step-by-step calculations, formulas, assumptions, and point estimates for each KPI] - - - -[Feature overview, KPI estimate table/list, key assumptions, sensitivity-analysis takeaways, and executive conclusions] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md b/.factory/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md deleted file mode 100644 index ba3f5a3b..00000000 --- a/.factory/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- - - - -# Feature results analysis from draft to final report - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-results-analysis-from-draft-to-final-report` -- **Lifecycle**: Launch & Learn -- **Category**: Analytics -- **Primary artifact**: Feature results readout with iterate, rollback, kill, or scale recommendation - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-features-reframing-and-projects-shape-up/SKILL.md b/.factory/skills/productize-features-reframing-and-projects-shape-up/SKILL.md deleted file mode 100644 index 0049fb31..00000000 --- a/.factory/skills/productize-features-reframing-and-projects-shape-up/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: productize-features-reframing-and-projects-shape-up -description: >- - Features reframing and projects Shape Up. Use when the user needs a product workflow for - technical related to features reframing and projects shape up. Trigger terms: - product-strategy, shaping, scope-management, stakeholder-management, technical. ---- - - - -# Features reframing and projects Shape Up - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `features-reframing-and-projects-shape-up` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Features reframing and projects Shape Up**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_OR_PROJECT}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Features reframing and projects Shape Up. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reframe `{{FEATURE_OR_PROJECT}}` using Shape Up principles and provided `{{CONTEXT}}`. -- Provide a shaped work definition that is concrete enough for delivery but avoids build-phase implementation detail. -- Include: -- Appetite assessment (`1-2 weeks` or `6 weeks`) with rationale. -- Problem framing (problem-first, not solution-first). -- Boundary definition (in-scope / out-of-scope). -- Solution sketch at fat-marker level. -- Risks/rabbit holes and circuit-breakers. -- Explicit no-gos. -- Executive constraint language to secure scope commitment and prevent mid-cycle scope creep. -- Keep output focused on shaping quality, delivery constraints, and stakeholder alignment. - -FORMAT -Return exactly this structure: - -Shape Up Reframe - -Appetite Assessment -- Recommended appetite: [1-2 weeks or 6 weeks] -- Why this appetite: [rationale] - -Problem Framing -- Core problem: [problem statement] -- Why this matters now: [impact/context] -- Success condition: [what success looks like] - -Boundary Definition -- In scope: - - [item] -- Out of scope: - - [item] - -Solution Sketching (Fat Marker Level) -- Key approach: [high-level approach] -- Main interaction/surface 1: [conceptual behavior] -- Main interaction/surface 2: [conceptual behavior] - -Risks and Rabbit Holes -- [risk/rabbit hole] -- Circuit-breaker: [constraint or stop-rule] - -No-gos -- [explicit exclusion] - -Executive Constraints -- Commitment language: [specific wording to secure scope agreement] -- Change-control rule: [how new requests are handled mid-cycle] -- Escalation path: [who decides if scope must change] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Output drifts into build-phase implementation details instead of shaping-level decisions. -- Boundaries/no-gos are vague or do not constrain scope. -- Executive constraint handling is missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-finance-modeling-kernel/SKILL.md b/.factory/skills/productize-finance-modeling-kernel/SKILL.md deleted file mode 100644 index 538d3739..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/SKILL.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: productize-finance-modeling-kernel -description: >- - Shared Productize Finance calculation and validation kernel for exact formulas, input - normalization, assumption checks, units, warnings, and acceptance-tested finance math used - by valuation, DCF, cost-of-capital, capital-structure, VC deal, and market-context skills. ---- - - - -# Finance Modeling Kernel - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `finance-modeling-kernel` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings - -## Purpose - -Shared calculation and validation library used by all Productize Finance skills. -Use this skill when a finance workflow needs exact formulas, normalized inputs, -assumption checks, error handling, units, or validation before making a recommendation. - -## Kernel Modules - -- `finance-modeling-kernel/time_value.py`: PV, FV, annuities, perpetuities, spot-rate streams. -- `finance-modeling-kernel/dcf.py`: NPV, IRR, payback, free cash flow, terminal value, ROIC, growth. -- `finance-modeling-kernel/returns.py`: realized returns, expected return, variance, volatility, covariance, correlation. -- `finance-modeling-kernel/risk.py`: portfolio variance, covariance, correlation, beta, regression beta. -- `finance-modeling-kernel/capm.py`: CAPM, unlevered beta, relevered beta. -- `finance-modeling-kernel/wacc.py`: WACC with market-value weights. -- `finance-modeling-kernel/apv.py`: tax shields and APV. -- `finance-modeling-kernel/valuation.py`: DCF valuation, terminal value, EV-to-equity bridge, multiples, sensitivities. -- `finance-modeling-kernel/capital_structure.py`: EV, equity value, leverage, MM, tax shields, APV. -- `finance-modeling-kernel/bond_math.py`: bond price, yield to maturity, current yield, credit spread. -- `finance-modeling-kernel/vc_method.py`: burn, runway, VC target multiple, pre/post-money, shares. -- `finance-modeling-kernel/cap_table.py`: fully diluted shares, ownership, dilution, cap table sum checks. -- `finance-modeling-kernel/convertible_notes.py`: note conversion amount, discount price, cap price, shares. -- `finance-modeling-kernel/safes.py`: SAFE conversion price, SAFE shares, post-money SAFE ownership. -- `finance-modeling-kernel/preferred_stock.py`: liquidation preference and preferred payoff waterfalls. -- `finance-modeling-kernel/option_pools.py`: investor-friendly and founder-friendly option pool math. -- `finance-modeling-kernel/market_context.py`: market cap, weights, listing changes, CAGR. -- `finance-modeling-kernel/validation.py`: shared validation errors and warning helpers. -- `finance-modeling-kernel/tests/`: acceptance tests for the minimum formula examples. - -## Finance Output Format - -All Productize Finance agents must return: - -1. **Inputs** -2. **Assumptions** -3. **Formula used** -4. **Calculation** -5. **Result** -6. **Interpretation** -7. **Warnings** - -## Global Guardrails - -1. Never compare cash flows at different dates without compounding or discounting. -2. Use market values, not book values, for valuation and WACC weights whenever possible. -3. Match discount rates to cash-flow risk. -4. Do not use a company WACC for a project with materially different risk. -5. Do not mix financing cash flows into operating free cash flow. -6. Use NPV as the primary investment decision rule. -7. Treat IRR, payback, and multiples as supporting tools, not final truth. -8. For VC deals, always state whether share counts are basic or fully diluted. -9. For option pools, always state whether the pool is investor-friendly or founder-friendly. -10. For convertible notes and SAFEs, always read the conversion definition before calculating. -11. For preferred stock, model the payoff waterfall, not only the ownership percentage. - -## Workflow - -1. Identify the finance problem and the cash-flow timing, units, currency, and risk basis. -2. Choose the exact module and function; do not invent ad hoc formulas when a kernel function exists. -3. Validate formula preconditions, especially `r > g`, positive denominators, share-count basis, and market-value weights. -4. Calculate transparently enough that the user can audit the math. -5. Return the standard Finance output format and warnings. - -## Acceptance Tests - -Run: - -```sh -python3 skills/finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py -``` - -The test suite covers DCF NPV, growing perpetuity, CAPM, WACC, VC target multiple, -post-money/pre-money, convertible note discount conversion, investor-friendly option -pool, and non-participating preferred payoff. diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py deleted file mode 100644 index 754f2374..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py +++ /dev/null @@ -1,10 +0,0 @@ -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py deleted file mode 100644 index bbbe83d7..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py +++ /dev/null @@ -1,36 +0,0 @@ -from validation import FinanceValidationError, require_positive - - -def bond_price(coupon, face_value, yield_to_maturity, periods): - if yield_to_maturity == 0: - return coupon * periods + face_value - return coupon * (1 - (1 + yield_to_maturity) ** (-periods)) / yield_to_maturity + face_value / (1 + yield_to_maturity) ** periods - - -def yield_to_maturity(price, coupon, face_value, periods, tolerance=1e-7, max_iterations=200): - require_positive("price", price) - low = -0.999999 - high = 1.0 - while bond_price(coupon, face_value, high, periods) > price and high < 1000: - high *= 2 - if high >= 1000: - raise FinanceValidationError("Yield to maturity could not be bracketed.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_price = bond_price(coupon, face_value, mid, periods) - if abs(mid_price - price) <= tolerance: - return mid - if mid_price > price: - low = mid - else: - high = mid - return (low + high) / 2 - - -def current_yield(annual_coupon, bond_price_value): - require_positive("bond_price", bond_price_value) - return annual_coupon / bond_price_value - - -def credit_spread(risky_yield, risk_free_yield): - return risky_yield - risk_free_yield diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py deleted file mode 100644 index 73d96466..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py +++ /dev/null @@ -1,19 +0,0 @@ -from validation import require_positive - - -def fully_diluted_shares(common=0, preferred_as_converted=0, options_issued=0, option_pool_unissued=0, warrants=0, convertibles=0): - return common + preferred_as_converted + options_issued + option_pool_unissued + warrants + convertibles - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares - - -def dilution(old_ownership_percentage, new_ownership_percentage): - require_positive("old_ownership_percentage", old_ownership_percentage) - return 1 - new_ownership_percentage / old_ownership_percentage - - -def cap_table_sums_to_100(ownership_percentages, tolerance=1e-6): - return abs(sum(ownership_percentages) - 1) <= tolerance diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py deleted file mode 100644 index e8e7565e..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py +++ /dev/null @@ -1,51 +0,0 @@ -from validation import require_positive - - -def enterprise_value(equity_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return equity_value + debt + preferred_stock + minority_interest - cash - nonoperating_assets - - -def equity_value_from_ev(enterprise_value_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def debt_to_equity(debt, equity): - require_positive("equity", equity) - return debt / equity - - -def debt_to_value(debt, equity): - require_positive("debt plus equity", debt + equity) - return debt / (debt + equity) - - -def degree_of_financial_leverage(ebit, interest): - require_positive("ebit minus interest", ebit - interest) - return ebit / (ebit - interest) - - -def wacc(equity, debt, cost_of_equity, cost_of_debt, tax_rate): - total = equity + debt - require_positive("debt plus equity", total) - return equity / total * cost_of_equity + debt / total * (1 - tax_rate) * cost_of_debt - - -def mm_value_no_taxes(unlevered_value): - return unlevered_value - - -def mm_cost_of_equity_no_taxes(unlevered_cost_of_capital, cost_of_debt, debt, equity): - require_positive("equity", equity) - return unlevered_cost_of_capital + debt / equity * (unlevered_cost_of_capital - cost_of_debt) - - -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py deleted file mode 100644 index 19a58da7..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py +++ /dev/null @@ -1,21 +0,0 @@ -from validation import require_positive - - -def capm_cost_of_equity(risk_free_rate, beta, market_risk_premium): - return risk_free_rate + beta * market_risk_premium - - -def unlever_beta(beta_l, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_l / (1 + (1 - tax_rate) * debt / equity) - - -def relever_beta(beta_u, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_u * (1 + (1 - tax_rate) * debt / equity) - - -def asset_beta_with_debt_beta(beta_equity, beta_debt, debt, equity, tax_rate=0): - require_positive("total capital", debt + equity) - tax_adjusted_debt = debt * (1 - tax_rate) - return (beta_equity * equity + beta_debt * tax_adjusted_debt) / (equity + tax_adjusted_debt) diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py deleted file mode 100644 index 9d05470a..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py +++ /dev/null @@ -1,27 +0,0 @@ -from validation import require_positive - - -def convertible_note_conversion_amount(principal, interest_rate, time, compounding_method="simple"): - if compounding_method == "simple": - return principal * (1 + interest_rate * time) - if compounding_method == "compound": - return principal * (1 + interest_rate) ** time - raise ValueError("compounding_method must be simple or compound.") - - -def convertible_note_discount_price(series_a_price, discount_rate): - return (1 - discount_rate) * series_a_price - - -def convertible_note_cap_price(valuation_cap, cap_share_count): - require_positive("cap_share_count", cap_share_count) - return valuation_cap / cap_share_count - - -def convertible_note_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def convertible_note_shares(conversion_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return conversion_amount / conversion_price diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py deleted file mode 100644 index 204cb98b..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py +++ /dev/null @@ -1,73 +0,0 @@ -from validation import FinanceValidationError, require_positive, require_rate_greater_than_growth - - -def npv(initial_investment, cash_flows, discount_rate): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def npv_with_terminal_value(initial_investment, fcfs, discount_rate, terminal_value): - return npv(initial_investment, fcfs, discount_rate) + terminal_value / (1 + discount_rate) ** len(fcfs) - - -def irr(cash_flows, tolerance=1e-7, max_iterations=200): - def value(rate): - return sum(cash_flow / (1 + rate) ** period for period, cash_flow in enumerate(cash_flows)) - - low = -0.999999 - high = 1.0 - low_value = value(low) - high_value = value(high) - while low_value * high_value > 0 and high < 1000: - high *= 2 - high_value = value(high) - if low_value * high_value > 0: - raise FinanceValidationError("IRR could not be bracketed; cash flows may have no real IRR or multiple IRRs.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_value = value(mid) - if abs(mid_value) <= tolerance: - return mid - if low_value * mid_value < 0: - high = mid - high_value = mid_value - else: - low = mid - low_value = mid_value - return (low + high) / 2 - - -def payback_period(cash_flows): - cumulative = 0 - for period, cash_flow in enumerate(cash_flows): - cumulative += cash_flow - if cumulative >= 0: - return period - return None - - -def discounted_payback_period(cash_flows, discount_rate): - discounted = [cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows)] - return payback_period(discounted) - - -def free_cash_flow(ebit, tax_rate, depreciation, capex, delta_nwc): - return ebit * (1 - tax_rate) + depreciation - capex - delta_nwc - - -def terminal_value_gordon(fcf_next, discount_rate, growth_rate): - require_rate_greater_than_growth(discount_rate, growth_rate, "discount_rate") - return fcf_next / (discount_rate - growth_rate) - - -def roic(nopat, invested_capital): - require_positive("invested_capital", invested_capital) - return nopat / invested_capital - - -def reinvestment_rate(capex, depreciation, delta_nwc, nopat): - require_positive("nopat", nopat) - return (capex - depreciation + delta_nwc) / nopat - - -def sustainable_growth(roic_value, reinvestment_rate_value): - return roic_value * reinvestment_rate_value diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py deleted file mode 100644 index 7596a040..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py +++ /dev/null @@ -1,34 +0,0 @@ -from validation import require_positive - - -def market_cap(price, shares_outstanding): - return price * shares_outstanding - - -def market_weight(company_market_cap, total_market_cap): - require_positive("total_market_cap", total_market_cap) - return company_market_cap / total_market_cap - - -def index_weight(company_market_cap, index_total_market_cap): - require_positive("index_total_market_cap", index_total_market_cap) - return company_market_cap / index_total_market_cap - - -def global_lookthrough_weight(index_weight_value, index_share_of_country_market, country_share_of_world_market): - return index_weight_value * index_share_of_country_market * country_share_of_world_market - - -def change_in_listings(start_listings, end_listings): - return end_listings - start_listings - - -def percentage_change(start_value, end_value): - require_positive("start_value", start_value) - return end_value / start_value - 1 - - -def cagr(beginning_value, ending_value, years): - require_positive("beginning_value", beginning_value) - require_positive("years", years) - return (ending_value / beginning_value) ** (1 / years) - 1 diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py deleted file mode 100644 index e593de1a..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py +++ /dev/null @@ -1,22 +0,0 @@ -def investor_friendly_option_pool(existing_shares, investor_target_ownership, target_option_pool): - total_post_money_shares = existing_shares / (1 - investor_target_ownership - target_option_pool) - investor_shares = investor_target_ownership * total_post_money_shares - option_pool_shares = target_option_pool * total_post_money_shares - existing_holder_ownership = existing_shares / total_post_money_shares - return { - "total_post_money_shares": total_post_money_shares, - "investor_shares": investor_shares, - "option_pool_shares": option_pool_shares, - "existing_holder_ownership": existing_holder_ownership, - } - - -def founder_friendly_option_pool(existing_shares, investor_shares, target_option_pool): - total_post_pool_shares = (existing_shares + investor_shares) / (1 - target_option_pool) - option_pool_shares = target_option_pool * total_post_pool_shares - investor_ownership_final = investor_shares / total_post_pool_shares - return { - "total_post_pool_shares": total_post_pool_shares, - "option_pool_shares": option_pool_shares, - "investor_ownership_final": investor_ownership_final, - } diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py deleted file mode 100644 index 2906dad5..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py +++ /dev/null @@ -1,19 +0,0 @@ -def liquidation_preference(investment, liquidation_multiple=1, accrued_dividends=0): - return investment * liquidation_multiple + accrued_dividends - - -def nonparticipating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership): - return max(liquidation_preference_value, as_converted_ownership * exit_value) - - -def participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences): - if exit_value <= total_preferences: - return min(exit_value, liquidation_preference_value) - return liquidation_preference_value + as_converted_ownership * (exit_value - total_preferences) - - -def capped_participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences, cap_multiple, investment): - uncapped = participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences) - capped = min(uncapped, cap_multiple * investment) - converted = as_converted_ownership * exit_value - return max(capped, converted) diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py deleted file mode 100644 index 7e925a81..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py +++ /dev/null @@ -1,48 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def realized_return(price_start, price_end, dividend=0): - require_positive("price_start", price_start) - return (price_end - price_start + dividend) / price_start - - -def expected_return(returns, probabilities): - require_same_length("returns", returns, "probabilities", probabilities) - return sum(probability * return_value for return_value, probability in zip(returns, probabilities)) - - -def variance(returns, probabilities): - mean = expected_return(returns, probabilities) - return sum(probability * (return_value - mean) ** 2 for return_value, probability in zip(returns, probabilities)) - - -def standard_deviation(returns, probabilities): - return sqrt(variance(returns, probabilities)) - - -def historical_average_return(returns): - require_positive("number of returns", len(returns)) - return sum(returns) / len(returns) - - -def portfolio_expected_return(weights, expected_returns): - require_same_length("weights", weights, "expected_returns", expected_returns) - return sum(weight * expected_return_value for weight, expected_return_value in zip(weights, expected_returns)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py deleted file mode 100644 index bf065db7..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py +++ /dev/null @@ -1,41 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def portfolio_variance(weights, covariance_matrix): - rows = len(covariance_matrix) - require_same_length("weights", weights, "covariance_matrix rows", covariance_matrix) - for row in covariance_matrix: - require_same_length("weights", weights, "covariance_matrix row", row) - return sum(weights[i] * weights[j] * covariance_matrix[i][j] for i in range(rows) for j in range(rows)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) - - -def beta(asset_returns, market_returns): - market_variance = covariance(market_returns, market_returns) - require_positive("market variance", market_variance) - return covariance(asset_returns, market_returns) / market_variance - - -def estimate_beta_regression(asset_returns, market_returns, risk_free_rates): - require_same_length("asset_returns", asset_returns, "market_returns", market_returns) - require_same_length("asset_returns", asset_returns, "risk_free_rates", risk_free_rates) - excess_asset = [asset - risk_free for asset, risk_free in zip(asset_returns, risk_free_rates)] - excess_market = [market - risk_free for market, risk_free in zip(market_returns, risk_free_rates)] - return beta(excess_asset, excess_market) diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py deleted file mode 100644 index b8fcc474..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py +++ /dev/null @@ -1,15 +0,0 @@ -from validation import require_positive - - -def safe_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def safe_shares(investment_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return investment_amount / conversion_price - - -def post_money_safe_ownership(investment_amount, post_money_valuation_cap): - require_positive("post_money_valuation_cap", post_money_valuation_cap) - return investment_amount / post_money_valuation_cap diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py deleted file mode 100644 index 6d7850ba..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py +++ /dev/null @@ -1,42 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth, require_same_length - - -def future_value(cash_flow, rate, periods): - return cash_flow * (1 + rate) ** periods - - -def present_value(cash_flow, rate, periods): - return cash_flow / (1 + rate) ** periods - - -def present_value_stream(cash_flows, rate): - return sum(present_value(cash_flow, rate, period) for period, cash_flow in enumerate(cash_flows, start=1)) - - -def present_value_with_spot_rates(cash_flows, spot_rates): - require_same_length("cash_flows", cash_flows, "spot_rates", spot_rates) - return sum(present_value(cash_flow, spot_rate, period) for period, (cash_flow, spot_rate) in enumerate(zip(cash_flows, spot_rates), start=1)) - - -def annuity_pv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * (1 - (1 + rate) ** (-periods)) / rate - - -def annuity_fv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * ((1 + rate) ** periods - 1) / rate - - -def perpetuity_pv(payment, rate): - require_positive("rate", rate) - return payment / rate - - -def growing_perpetuity_pv(next_payment, rate, growth_rate): - require_rate_greater_than_growth(rate, growth_rate) - return next_payment / (rate - growth_rate) diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py deleted file mode 100644 index a94535ec..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py +++ /dev/null @@ -1,33 +0,0 @@ -class FinanceValidationError(ValueError): - """Raised when a finance formula cannot be applied safely.""" - - -def require_positive(name, value): - if value <= 0: - raise FinanceValidationError(f"{name} must be positive.") - return value - - -def require_nonnegative(name, value): - if value < 0: - raise FinanceValidationError(f"{name} must be nonnegative.") - return value - - -def require_rate_greater_than_growth(rate, growth_rate, rate_name="rate"): - if rate <= growth_rate: - raise FinanceValidationError(f"{rate_name} must be greater than growth rate.") - - -def require_same_length(name_a, values_a, name_b, values_b): - if len(values_a) != len(values_b): - raise FinanceValidationError(f"{name_a} and {name_b} must have the same length.") - - -def warn_if(condition, message, warnings=None): - if not condition: - return warnings if warnings is not None else [] - if warnings is None: - warnings = [] - warnings.append(message) - return warnings diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py deleted file mode 100644 index 5c97d94a..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py +++ /dev/null @@ -1,55 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth - - -def value_project_dcf(cash_flows, discount_rate, initial_investment): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def value_company_dcf(free_cash_flows, wacc, terminal_value): - return sum(fcf / (1 + wacc) ** period for period, fcf in enumerate(free_cash_flows, start=1)) + terminal_value / (1 + wacc) ** len(free_cash_flows) - - -def calculate_terminal_value_gordon(fcf_next, wacc, growth_rate): - require_rate_greater_than_growth(wacc, growth_rate, "wacc") - return fcf_next / (wacc - growth_rate) - - -def calculate_terminal_value_exit_multiple(metric, multiple): - return metric * multiple - - -def bridge_enterprise_to_equity_value(enterprise_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def calculate_price_per_share(equity_value, diluted_shares): - require_positive("diluted_shares", diluted_shares) - return equity_value / diluted_shares - - -def run_comparable_company_valuation(company_metric, comparable_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in comparable_multiples] - - -def run_precedent_transaction_valuation(company_metric, transaction_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in transaction_multiples] - - -def calculate_implied_multiple(value, metric): - require_positive("metric", metric) - return value / metric - - -def calculate_implied_value(metric, multiple): - return metric * multiple - - -def run_sensitivity_table(inputs, output_metric): - rows = [] - for case_name, case_inputs in inputs.items(): - rows.append({"case": case_name, "value": output_metric(**case_inputs)}) - return rows - - -def run_scenario_analysis(base_case, upside_case, downside_case): - return {"base": base_case, "upside": upside_case, "downside": downside_case} diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py deleted file mode 100644 index 77d56314..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py +++ /dev/null @@ -1,57 +0,0 @@ -from validation import require_positive - - -def burn_rate(monthly_expenses, monthly_cash_receipts=0): - return monthly_expenses - monthly_cash_receipts - - -def runway(cash_balance, monthly_net_burn): - require_positive("monthly_net_burn", monthly_net_burn) - return cash_balance / monthly_net_burn - - -def vc_target_multiple(required_return, holding_period, probability_success): - require_positive("probability_success", probability_success) - return (1 + required_return) ** holding_period / probability_success - - -def vc_present_value(successful_exit_value, probability_success, required_return, holding_period): - return successful_exit_value * probability_success / (1 + required_return) ** holding_period - - -def vc_total_valuation(successful_exit_value, retention, target_multiple): - require_positive("target_multiple", target_multiple) - return successful_exit_value * retention / target_multiple - - -def vc_partial_valuation(proposed_ownership, total_valuation): - return proposed_ownership * total_valuation - - -def vc_required_ownership(required_investment, total_valuation): - require_positive("total_valuation", total_valuation) - return required_investment / total_valuation - - -def post_money(investment, ownership): - require_positive("ownership", ownership) - return investment / ownership - - -def pre_money(post_money_value, investment): - return post_money_value - investment - - -def price_per_share(pre_money_value, fully_diluted_pre_money_shares): - require_positive("fully_diluted_pre_money_shares", fully_diluted_pre_money_shares) - return pre_money_value / fully_diluted_pre_money_shares - - -def new_shares(investment, price_per_share_value): - require_positive("price_per_share", price_per_share_value) - return investment / price_per_share_value - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares diff --git a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py b/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py deleted file mode 100644 index b147c830..00000000 --- a/.factory/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py +++ /dev/null @@ -1,9 +0,0 @@ -from validation import require_positive - - -def wacc(equity_value, debt_value, cost_of_equity, cost_of_debt, tax_rate): - total_value = equity_value + debt_value - require_positive("debt plus equity", total_value) - equity_weight = equity_value / total_value - debt_weight = debt_value / total_value - return equity_weight * cost_of_equity + debt_weight * (1 - tax_rate) * cost_of_debt diff --git a/.factory/skills/productize-financial-markets-context/SKILL.md b/.factory/skills/productize-financial-markets-context/SKILL.md deleted file mode 100644 index f0ea115f..00000000 --- a/.factory/skills/productize-financial-markets-context/SKILL.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -name: productize-financial-markets-context -description: >- - Productize Finance context skill for market capitalization, market weights, index - concentration, listed-firm trends, public-company comparables, sector shifts, and CAPM - market-portfolio assumptions. ---- - - - -# Financial Markets Context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `financial-markets-context` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings - -## Purpose - -Market context skill. Use it to interpret public-market facts, index concentration, -listed-firm trends, market capitalization, comparable-company assumptions, sector -shifts, and market portfolio assumptions in CAPM. - -## Core Formulas - -- `Market Cap_i = Share Price_i * Shares Outstanding_i` -- `Weight_i = Market Cap_i / Total Market Cap` -- `Index Weight_i = Market Cap_i / sum(Market Cap of All Index Constituents)` -- `Global Weight_i = index weight * index share of country market * country share of world market` -- `Change in Listings = Listings_End - Listings_Start` -- `% Change = (End / Start - 1) * 100` -- `CAGR = (Ending Value / Beginning Value)^(1 / Years) - 1` - -## Interpretation Rules - -- Fewer listed firms does not necessarily mean a smaller equity market. -- Market capitalization can rise even if listings fall. -- This can happen because public firms become larger, smaller firms delist, and mergers concentrate value. -- Index concentration matters because the CAPM market portfolio is value-weighted. -- Public comparables may be biased if the target is much smaller, less mature, less profitable, or in a different sector. -- Sector composition changes over time, so historical index returns may reflect sector shifts, not only broad economic growth. - -## Required Validation - -- Warn if equal weighting is confused with value weighting. -- Warn if index concentration is ignored. -- Warn if public comparables are used for a startup without maturity adjustments. -- Warn if global market assumptions use only one domestic index. -- Warn if stale market weights are used. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Separate market fact, valuation implication, and comparability risk. diff --git a/.factory/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md b/.factory/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md deleted file mode 100644 index 55ad6c4c..00000000 --- a/.factory/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md +++ /dev/null @@ -1,422 +0,0 @@ ---- -name: productize-fragmented-user-research-synthesis-into-coherent-insights -description: >- - Fragmented user research synthesis into coherent insights. Use when the user needs a product - workflow for user research related to fragmented user research synthesis into coherent - insights. Trigger terms: user-research, synthesis, insights. ---- - - - -# Fragmented user research synthesis into coherent insights - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `fragmented-user-research-synthesis-into-coherent-insights` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Fragmented user research synthesis into coherent insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{RESEARCH_INPUTS}} -- {{PRODUCT_CONTEXT}} -- {{DESIGN_QUESTIONS}} -- {{CURRENT_ASSUMPTIONS}} -- {{BUSINESS_GOALS}} - - -GOAL -Produce a high-quality deliverable for: Fragmented user research synthesis into coherent insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Synthesize fragmented research inputs into coherent, evidence-based insights that inform design and product decisions. -- Use the provided inputs: -- `{{RESEARCH_INPUTS}}` -- `{{PRODUCT_CONTEXT}}` -- `{{DESIGN_QUESTIONS}}` -- `{{CURRENT_ASSUMPTIONS}}` -- `{{BUSINESS_GOALS}}` -- Perform synthesis rigorously: -- Inventory and assess source quality/coverage. -- Extract coded observations (quotes, behaviors, themes, segment/context metadata). -- Identify cross-source patterns and contradictions. -- Assign confidence levels with explicit rationale. -- Map insights to JTBD and user-needs hierarchy. -- Link insights directly to design questions and actionable recommendations. -- Identify research gaps, unresolved assumptions, and prioritized follow-up research. -- Keep evidence traceable, avoid over-generalization, and state assumptions/uncertainties explicitly. - -FORMAT -Return exactly this structure: - - - -**Data Sources Summary:** -- User interviews: [X participants] covering [topics, user segments, dates] -- Support tickets: [Y tickets] from [date range] about [primary themes] -- NPS feedback: [Z responses] with [average score] discussing [key topics] -- Usage analytics: [data range, key metrics, user actions analyzed] -- Feature requests: [count] requests across [platforms/sources] -- Usability tests: [sessions count] testing [specific flows or features] -- Survey data: [respondents count] on [topics covered] -- Anecdotal feedback: [source count] from [stakeholders, channels] -- Session recordings: [count] sessions showing [behaviors] -- Other sources: [specify any additional data] - -**Data Quality Assessment:** -- Time range: [how recent is this data?] -- User segment coverage: [which personas/segments are represented?] -- Sample size adequacy: [sufficient for confidence in findings?] -- Potential bias: [what perspectives might be over/under-represented?] -- Data completeness: [what's missing or sparse?] - - - - -**Insight Statement:** -[One clear, specific sentence stating what you learned about users] - -**Evidence:** -- User interviews: "[verbatim quote]" (Participant X, [segment]) -- Support tickets: [Y tickets] report "[specific issue]" with keywords: [terms] -- NPS feedback: "[example comment]" (common theme in Z% of detractor responses) -- Analytics data: [X% of users] exhibit [specific behavior], [frequency/context] -- Additional evidence: [any other supporting data points] - -**Confidence Level:** High / Medium / Low -**Rationale for Confidence:** [Why you assigned this confidence level] - -**User Segments Affected:** -- [Segment 1]: [how this manifests for them] -- [Segment 2]: [how this manifests for them] - -**Jobs-to-be-Done Connection:** -[Which job is this insight related to? How does it help or hinder job completion?] - -**Design Implications:** -- Consider: [specific design approach this suggests] -- Avoid: [what this insight argues against] -- Prioritize: [which aspect of the experience to focus on] -- Measure: [how to validate design addressed this insight] - -**Related Patterns:** -[Which other insights connect to this? How do they reinforce or complicate each other?] - -**Business Impact:** -[How does addressing this insight connect to business goals or metrics?] - - - -[Repeat the full structure for 5-10 key insights, maintaining consistent depth and evidence rigor] - - - -[Continue for all major insights...] - - - - -**Conflict 1:** -- Signal A: [what one source or segment indicates] -- Signal B: [what contradicts this] -- Possible explanations: - * [Explanation 1: e.g., different user segments with different needs] - * [Explanation 2: e.g., stated preference vs. actual behavior] - * [Explanation 3: e.g., context-dependent variation] -- Recommended resolution: [What research or analysis would clarify this?] -- Design strategy given conflict: [How to proceed despite uncertainty?] - -**Conflict 2:** -[Repeat structure for each major contradiction in the data] - -**Synthesis:** -[What do these conflicts reveal about user diversity, product complexity, or research gaps?] - - - -**Question 1:** [Restate the first design question] -- **Answer based on research:** [What the data tells you] -- **Supporting insights:** [Which insights from above inform this answer] -- **Confidence level:** High / Medium / Low -- **Caveats and limitations:** [What qualifies or nuances this answer] -- **What we still don't know:** [Gaps specific to this question] -- **Recommended action:** [What to design/test/research next] - -**Question 2:** [Restate the second design question] -[Repeat structure for each design question provided] - -**New Questions Surfaced:** -[Design questions that emerged from the research but weren't originally asked] - - - - -**Must-Have Needs (Strong Evidence, High Impact):** -1. [Need 1]: [description] - - Evidence: [cross-source validation] - - If unmet: [severe user/business consequence] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat structure for 3-5 critical needs] - - - -**Should-Have Needs (Moderate Evidence, Meaningful Impact):** -1. [Need 1]: [description] - - Evidence: [validation from 1-2 strong sources] - - If unmet: [moderate user friction or business impact] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat for 5-8 important needs] - - - -**Nice-to-Have Needs (Weak Signal, Low/Uncertain Impact):** -1. [Need 1]: [description] - - Evidence: [limited mentions or single source] - - Potential value: [why this might matter despite weak signal] - - Validation needed: [how to test if this is actually important] - -2. [Need 2]: [description] - [Repeat for 3-5 nice-to-have needs] - - - -**Segment-Specific Needs:** -- [Segment A]: [unique needs not shared by other segments] -- [Segment B]: [unique needs not shared by other segments] -- [Universal needs]: [needs expressed across all segments] - - - - -**Current Workflows and Workarounds:** -[Describe how users actually accomplish tasks today, including inefficient or creative workarounds that reveal unmet needs] - -**Decision-Making Patterns:** -[How users make choices within the product, what information they seek, what causes hesitation or confidence] - -**Pain Point Triggers:** -[Specific circumstances, contexts, or actions that consistently lead to user frustration] - -**Success Patterns:** -[When and how users successfully achieve their goals, what enables their success] - -**Usage Context and Frequency:** -[When, where, why, and how often users engage with the product or specific features] - -**Adoption and Learning Patterns:** -[How users onboard themselves, what helps or hinders learning, common confusion points] - -**Abandonment and Recovery Patterns:** -[What causes users to give up, what brings them back, how they recover from errors] - -**Cross-Tool Workflows:** -[How users combine your product with other tools, what gaps force tool-switching] - - - -**Primary Functional Jobs:** -1. [Job]: When [situation], I want to [motivation], so I can [expected outcome] - - Evidence: [how research revealed this job] - - Current obstacles: [what prevents job completion] - - Success criteria: [how users define successful job completion] - -2. [Job]: [Repeat structure for 3-5 primary jobs] - -**Emotional Jobs:** -- [Feel]: [emotion users want to feel, e.g., "feel confident in my decisions"] -- [Avoid]: [emotion users want to avoid, e.g., "avoid feeling overwhelmed"] -- Evidence: [quotes, observations, sentiment indicators] - -**Social Jobs:** -- [Perception]: [how users want to be seen, e.g., "be perceived as data-driven"] -- [Context]: [social situations where product use matters] -- Evidence: [research indicators of social motivations] - -**Related Jobs in the Consumption Chain:** -- Before main job: [how users discover, evaluate, and choose the product] -- After main job: [how users share, report, or build on outcomes] -- Maintenance jobs: [ongoing tasks to keep getting value] - - - - -**Critical Unknowns (Blocking Design Decisions):** -1. [Question]: [why this matters for design] -2. [Question]: [why this matters for design] -3. [Question]: [why this matters for design] - -**Important Unknowns (Would Significantly Inform Design):** -1. [Question]: [how this would help] -2. [Question]: [how this would help] - -**Curiosities (Interesting But Not Urgent):** -1. [Question]: [potential value] -2. [Question]: [potential value] - - - -**Research Activity 1:** -- **Method:** [interviews / usability testing / survey / analytics deep-dive / diary study / etc.] -- **Target participants:** [which user segments, how many, recruitment criteria] -- **Key questions to answer:** [specific questions this research would resolve] -- **Expected outcomes:** [what you'll learn and how it informs design] -- **Effort estimate:** [time and resources required] -- **Priority:** High / Medium / Low - [rationale] - -**Research Activity 2:** -[Repeat structure for 3-5 recommended research activities, prioritized by impact and urgency] - - - -**Design Assumptions:** -1. [Assumption about user behavior or preferences]: Currently [validated / unvalidated / contradicted] by research -2. [Assumption about priorities or needs]: Currently [status] -3. [Assumption about technical or business constraints]: Currently [status] - -**Team Assumptions:** -[Assumptions stakeholders or team members hold that aren't supported by dataโ€”list with gentle evidence-based reframing] - -**Testing Strategy:** -[How to quickly validate or invalidate the most critical assumptions through lightweight tests] - - - - -**Priority 1 Recommendations (Supported by High-Confidence Insights):** -1. [Specific design action]: [rationale tied to insight X, Y, Z] - - Expected impact: [user and business outcomes] - - Success metrics: [how to measure if this worked] - -2. [Specific design action]: [rationale tied to insights] - [Repeat for 3-5 top-priority recommendations] - -**Priority 2 Recommendations (Supported by Medium-Confidence Insights):** -1. [Specific design action]: [rationale] - [Repeat for 5-7 secondary recommendations] - -**Quick Wins (Low Effort, Clear User Value):** -1. [Specific design action]: [why this is easy and valuable] - [Repeat for 3-5 quick wins] - -**Strategic Bets (Lower Confidence, High Potential):** -1. [Specific design action]: [why worth exploring despite uncertainty] - - Validation approach: [how to test before full commitment] - [Repeat for 2-3 strategic bets] - -**Do Not Pursue:** -[Features, changes, or directions that research argues against, with rationale] - - - -**Executive Summary** - -**What We Learned:** -[2-3 sentences capturing the most important insights from the research] - -**User Needs Priority:** -Users critically need [top need], strongly want [second need], and would appreciate [third need]. The evidence is strongest for [insight area] and weakest for [insight area requiring validation]. - -**Key Behavioral Patterns:** -[1-2 sentences on how users actually behave vs. what we might have assumed] - -**Design Implications:** -The research strongly supports [recommended direction 1] and [recommended direction 2], while arguing against [current assumption or planned direction]. We should prioritize [specific user segment or job-to-be-done] because [evidence-based rationale]. - -**Critical Unknowns:** -We still need to understand [key gap 1] and [key gap 2] through [recommended research method]. - -**Recommended Next Steps:** -1. [Immediate action based on high-confidence insights] -2. [Design exploration for medium-confidence opportunities] -3. [Targeted research to fill critical gaps] - -**Business Impact:** -Addressing these insights is expected to improve [business metric] by [directional estimate] because [user behavior change expected]. - -[Total: 250-350 words] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Insights are not supported by cross-source evidence or confidence rationale. -- Contradictions are ignored or not addressed with a resolution approach. -- Recommendations are not prioritized or not linked to synthesized insights/business goals. -- Research gaps and assumption validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md b/.factory/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md deleted file mode 100644 index fc5dbcfc..00000000 --- a/.factory/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -name: productize-framework-application-to-product-challenges-from-user-input -description: >- - Framework application to product challenges from user input. Use when the user needs a - product workflow for product strategy related to framework application to product challenges - from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching. ---- - - - -# Framework application to product challenges from user input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `framework-application-to-product-challenges-from-user-input` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Framework application to product challenges from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRAMEWORK}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Framework application to product challenges from user input. -Success metric: -- Asks targeted questions when key context is missing. -- Applies the provided framework precisely to the userโ€™s situation. -- Produces actionable advice and a clear recommendation when sufficient context exists. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{FRAMEWORK}}` and `{{USER_INPUT}}`; if key context is missing, ask targeted questions first. -- Do not summarize the framework back to the user. -- When asking for more information, use `` tags only. -- When providing guidance, use `` tags only. -- When providing a final recommendation, use `` tags only. -- Keep advice specific and grounded in the userโ€™s context; avoid generic PM guidance. - -FORMAT -Return exactly this structure: - - -[Targeted questions needed to apply the framework] - - - -[Framework-applied guidance once sufficient context exists] - - - -[Final recommendation when enough context exists] - - -FAILURE -- Required tags are missing or malformed. -- Output includes framework summary instead of application. -- Advice is generic or not tied to the user input. -- Recommendation is provided without sufficient context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-frontend-design/SKILL.md b/.factory/skills/productize-frontend-design/SKILL.md deleted file mode 100644 index b21a1c23..00000000 --- a/.factory/skills/productize-frontend-design/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-frontend-design -description: >- - Design implementation-ready frontend solutions with UX intent, component structure, - responsive behavior, accessibility, and handoff criteria. ---- - - - -# Frontend Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `frontend-design` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to design frontend behavior and UI structure before or alongside implementation. - -## The Process - -### Step 1: Define UX objective - -Capture: -- user goal -- primary user flow -- success state and failure states - -### Step 2: Specify UI architecture - -Define: -- screen/layout structure -- component hierarchy -- state model (loading, empty, error, success) - -### Step 3: Specify design system decisions - -Set: -- typography and spacing rules -- color/contrast constraints -- interaction patterns - -### Step 4: Specify responsive and accessibility requirements - -Include: -- breakpoints and behavior changes -- keyboard navigation expectations -- ARIA/semantic requirements -- contrast and focus visibility requirements - -### Step 5: Define implementation handoff - -Provide: -- component list and props/state contract -- acceptance criteria -- verification checklist - -## Output Format - -```markdown -# [Feature Name] Frontend Design Spec - -## UX Objective -- User goal: -- Primary flow: -- Success/failure states: - -## UI Architecture -- Layout: -- Component hierarchy: -- State model: - -## Responsive Behavior -- Desktop: -- Tablet: -- Mobile: - -## Accessibility Requirements -- Keyboard: -- Semantics/ARIA: -- Contrast/focus: - -## Handoff -- Components to implement: -- Acceptance criteria: -- Verification checklist: -``` - -## Quality Bar - -- Design decisions must map to user goals -- Accessibility section is mandatory -- Handoff must be implementable without extra interpretation - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/.factory/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md b/.factory/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md deleted file mode 100644 index 62097374..00000000 --- a/.factory/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: productize-future-product-opportunities-from-market-inflection-points -description: >- - Future product opportunities from market inflection points. Use when the user needs a - product workflow for product strategy related to future product opportunities from market - inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, - trends, product-vision. ---- - - - -# Future product opportunities from market inflection points - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `future-product-opportunities-from-market-inflection-points` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Future product opportunities from market inflection points**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_YEAR}} -- {{RESEARCH_TIMEFRAME}} - - -GOAL -Produce a high-quality deliverable for: Future product opportunities from market inflection points. -Success metric: -- Identifies concrete regulatory, technological, and belief inflection points within the stated timeframe. -- Connects converging trends to 3โ€“5 plausible future opportunities. -- Provides actionable challenges and timelines for each opportunity. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_YEAR}}` and `{{RESEARCH_TIMEFRAME}}`; if context is missing, state assumptions explicitly. -- List 3โ€“5 items per inflection category (regulatory, technological, belief). -- Provide 3โ€“5 converging trend sets that explicitly combine at least two categories. -- Provide 3โ€“5 future opportunities with concept, enabling trends, challenges, and timeline. -- Keep opportunities plausible within the specified research timeframe. - -FORMAT -Return exactly this structure: - - -1. Inflection Points: - a. Regulatory: - - [List 3โ€“5 significant regulatory changes] - b. Technological: - - [List 3โ€“5 important technological advancements] - c. Belief: - - [List 3โ€“5 notable shifts in societal attitudes or behaviors] - -2. Converging Trends: - - [Describe 3โ€“5 sets of converging trends, explaining how they intersect] - -3. Future Opportunities: - [For each opportunity (aim for 3โ€“5), include:] - a. Concept: [Brief description] - b. Enabling Trends: [List the key inflection points or converging trends] - c. Challenges: [Potential barriers or difficulties] - d. Timeline: [Estimated timeframe for realization] - -4. Conclusion: - [Summarize the most promising areas for innovation based on your analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any inflection category has fewer than 3 or more than 5 items. -- Converging trends do not combine multiple categories. -- Opportunities are missing required fields or outside the specified timeframe. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-group-decision-making-quality-review/SKILL.md b/.factory/skills/productize-group-decision-making-quality-review/SKILL.md deleted file mode 100644 index cb5bacdc..00000000 --- a/.factory/skills/productize-group-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: productize-group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, or - operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group - decides. ---- - - - -# Group Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `group-decision-making-quality-review` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/.factory/skills/productize-grow/SKILL.md b/.factory/skills/productize-grow/SKILL.md deleted file mode 100644 index c1b5d4fb..00000000 --- a/.factory/skills/productize-grow/SKILL.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: productize-grow -description: >- - Productize grow playbook for stable products with activation evidence. Use when the product - has a working core and the team needs growth diagnosis, growth loops, GTM choices, - onboarding, retention, pricing, lifecycle triggers, and experiment cadence. ---- - - - -# Productize Grow - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `grow` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition - -Use this playbook when the core product is stable enough to grow. Grow is not the -place to invent the product; use `$0-1` for new bets and `$operate` for continuous -production health. - -## Cadence - -- Trigger: stable activation, repeat usage, clear ICP, or a growth bottleneck. -- Rhythm: weekly experiment planning and readout, with metric reviews before changing - channels, onboarding, pricing, or lifecycle triggers. -- Closure: target hit, target abandoned, strategy pivot, or evidence that the product - needs a new `$0-1` loop. - -## Route Internally - -- Product-market fit and bottlenecks: `$product-market-fit-cycle`, `$aarrr-growth-diagnostics`, `$metrics-review` -- Loops and experiments: `$growth-loops`, `$plg-growth-playbook`, `$growth-project-generation-with-pioneer-migrator-settler`, `$robust-experiment-design-from-goals-and-systems` -- GTM and lifecycle: `$gtm-motions`, `$gtm-strategy`, `$onboarding-flow-optimization-from-product-data-to-user-success` -- Retention and monetization: `$churn-reduction-from-customer-data-and-exit-survey-analysis`, `$pricing-strategy`, `$monetization-strategy` -- Gates: `$product-review`, `$qa`, `$comms-review`, `$docs`, `$release` - -## Required Output - -Return: - -1. **Growth State**: ICP, activation evidence, retention signal, bottleneck, and metric caveats. -2. **Growth Thesis**: target, growth loop, channel or lifecycle trigger, and why it fits the current evidence. -3. **Experiment Cadence**: tests, owners, sample size or evidence threshold, and stop/pivot rules. -4. **Gate Calls**: product, QA, docs, release, or comms gates needed before launch. -5. **Closure Condition**: target hit, pivot, pause, or new `$0-1` bet. diff --git a/.factory/skills/productize-growth-loops/SKILL.md b/.factory/skills/productize-growth-loops/SKILL.md deleted file mode 100644 index 4f439fbc..00000000 --- a/.factory/skills/productize-growth-loops/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: productize-growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- - - - -# Growth Loops - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-loops` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.factory/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md b/.factory/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md deleted file mode 100644 index 4c847103..00000000 --- a/.factory/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-growth-project-generation-with-pioneer-migrator-settler -description: >- - Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a - product workflow for product strategy related to growth project generation with - pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, - portfolio. ---- - - - -# Growth project generation with Pioneer-Migrator-Settler framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-project-generation-with-pioneer-migrator-settler` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Growth project generation with Pioneer-Migrator-Settler framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY}} - - -GOAL -Produce a high-quality deliverable for: Growth project generation with Pioneer-Migrator-Settler framework. -Success metric: -- Produces 12 distinct growth projects categorized into Pioneer/Migrator/Settler. -- Ensures balanced portfolio logic and a brief plan to drive growth. -- Keeps ideas concrete, differentiated, and aligned to the company context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY}}`; if details are missing, state assumptions explicitly. -- Generate exactly 12 distinct growth projects: - - 3 creative, - - 3 weird, - - 3 compelling, - - 3 novel and unexpected. -- Each idea must be tagged as one of: Pioneer, Migrator, Settler. -- Keep ideas concrete and specific to the companyโ€™s context. -- Provide a brief analysis of portfolio balance and strategic impact. -- Provide a short growth plan for how to build new market space and profitable growth. - -FORMAT -Return exactly this structure: - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - - -[Brief analysis of mix and impact, with portfolio balance insights] - - - -[Brief plan for creating new market space and profitable growth] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer or more than 12 ideas are provided. -- Any idea is missing a Pioneer/Migrator/Settler category. -- Ideas are generic or not grounded in the company context. -- Analysis or growth plan is missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md b/.factory/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md deleted file mode 100644 index 99d9f24c..00000000 --- a/.factory/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: productize-growth-strategy-synthesis-from-user-inputs -description: >- - Growth strategy synthesis from user inputs. Use when the user needs a product workflow for - product strategy related to growth strategy synthesis from user inputs. Trigger terms: - growth, strategy, experimentation, metrics, distribution. ---- - - - -# Growth strategy synthesis from user inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-strategy-synthesis-from-user-inputs` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth strategy brief with bets, loops, experiments, and metrics - -Use this skill to run the Productize prompt contract for **Growth strategy synthesis from user inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUTS}} - - -GOAL -Produce a high-quality deliverable for: Growth strategy synthesis from user inputs. -Success metric: -- Produces a complete growth strategy across model, constraints, horizon, method, principle, and catalyst. -- Grounds all recommendations in the provided user inputs. -- Outputs actionable, testable recommendations and a concise summary. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUTS}}`; if critical data is missing, state assumptions explicitly. -- Address each required section: model, constraint, horizon, method, principle, catalyst, summary. -- Keep recommendations actionable and testable; avoid generic advice. -- If quantitative data is present, reference it; if not, use qualitative reasoning and label assumptions. - -FORMAT -Return exactly this structure: - - - -[Provide a detailed description of the growth model] - - - -[Identify and explain the main growth constraints] - - - -[Analyze the growth horizon and potential limitations] - - - -[Propose specific methods to address constraints and extend the growth horizon] - - - -[Develop a guiding principle for aligning the organization] - - - -[Identify and explain any growth catalysts] - - - -[Provide a brief summary of the overall growth strategy] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Recommendations are not tied to the provided inputs. -- Growth method lacks actionable steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-gtm-motions/SKILL.md b/.factory/skills/productize-gtm-motions/SKILL.md deleted file mode 100644 index a9650ffb..00000000 --- a/.factory/skills/productize-gtm-motions/SKILL.md +++ /dev/null @@ -1,236 +0,0 @@ ---- -name: productize-gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, - partner, ABM, or hybrid go-to-market motions. ---- - - - -# GTM Motions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-motions` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.factory/skills/productize-gtm-strategy/SKILL.md b/.factory/skills/productize-gtm-strategy/SKILL.md deleted file mode 100644 index 22360c0b..00000000 --- a/.factory/skills/productize-gtm-strategy/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: productize-gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- - - - -# GTM Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.factory/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md b/.factory/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md deleted file mode 100644 index 5d62c3c7..00000000 --- a/.factory/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- - - - -# Ideal Customer Profile (ICP) representative for X product - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideal-customer-profile-icp-representative-for-x-product` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.factory/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md b/.factory/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md deleted file mode 100644 index 3be9171c..00000000 --- a/.factory/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md +++ /dev/null @@ -1,171 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make ICP outputs sharper on demographics, behaviors, JTBD, PMF evidence, and best-customer patterns. - -## Routing Signals - -- ideal customer profile -- icp -- pmf survey -- best customers - -## pm-go-to-market/skills/ideal-customer-profile/SKILL.md - -## Overview -Identify your Ideal Customer Profile (ICP) from research and survey data. This skill synthesizes customer research to define the customer most likely to find value, retain, and expand with your product. - -## When to Use -- Defining ICP from product-market fit survey data -- Targeting high-value customer segments -- Analyzing customer success and expansion patterns -- Prioritizing sales and marketing efforts -- Evaluating new customer opportunities for fit -- Refining target market definition - -## ICP Framework Components - -### Demographics -Who are they from a firmographic and personal perspective? -- Company size (employees, revenue) -- Industry or vertical -- Geographic location -- Job title and department -- Years of experience in role -- Education and background -- Organizational structure and reporting - -### Behaviors -How do they work and make decisions? -- How they discover and evaluate solutions -- Buying process and decision-making timeline -- Technical literacy and product adoption speed -- Collaboration style (solo decision vs committee) -- Change management and adoption style -- Tool switching frequency -- Community involvement and peer influence - -### Jobs to Be Done (JTBD) -What are they trying to accomplish? -- Primary job/goal they're trying to achieve -- Secondary jobs that support the primary job -- Emotional jobs (how they want to feel) -- Social jobs (status and perception) -- Jobs they avoid or want to eliminate -- Frequency and importance of each job -- Success metrics for completing job - -### Needs and Pain Points -What problems does your product solve? -- Specific pain points they experience -- Current workarounds and limitations -- Impact on productivity or outcomes -- Cost or time burden of the problem -- Emotional frustration levels -- Barriers to solving the problem -- Available budget to solve -- Competing priorities - -## How It Works - -### Step 1: Gather Customer Data -Collect research about actual and potential customers: -- Product-market fit survey responses -- Customer interview transcripts -- Trial or freemium user behavior data -- Customer feedback and support tickets -- Churn analysis and customer lifecycle data -- Win/loss analysis from sales -- Competitor customer analysis - -### Step 2: Segment by Value -Identify customer cohorts and their value: -- Highest LTV (lifetime value) customers -- Fastest time-to-value customers -- Lowest churn rate customers -- Highest expansion/upsell customers -- Most enthusiastic/engaged customers -- Best reference/case study potential -- Most aligned with product vision - -### Step 3: Profile Demographics -Extract firmographic patterns: -- Common company sizes (employee count, revenue) -- Industry verticals and sub-verticals -- Geographic concentrations -- Typical department and reporting structure -- Budget holders and budget available -- Company stage (startup, growth, enterprise) -- Company culture indicators - -### Step 4: Identify Behaviors -Map decision-making and adoption patterns: -- How they discovered your product (channel) -- Evaluation process and timeline -- Key stakeholders in decision -- Obstacles during sales process -- Product adoption speed and breadth -- Team involvement in onboarding -- Frequency of feature usage -- Support and service needs - -### Step 5: Define JTBD -Articulate what they're trying to accomplish: -- Primary job/goal (functional job) -- Emotional dimensions (how they want to feel) -- Social dimensions (team and stakeholder impact) -- Success metrics (how they measure success) -- Context and constraints (when, where, with whom) -- Competing jobs and priorities -- Importance ranking of various jobs - -### Step 6: Document Pain Points and Needs -Synthesize specific problem areas: -- Before state (current situation and frustrations) -- Desired after state (ideal future state) -- Gap size and impact quantification -- Emotional dimensions of the problem -- Resource constraints preventing solutions -- Skepticism or hesitations -- Success criteria for solution - -## Input Format -Use $ARGUMENTS to pass: -- Research data (surveys, interviews, transcripts) -- Customer success/metrics data -- Product usage analytics -- Sales activity and win/loss data -- Existing customer database -- Competitive intelligence - -## Output -A comprehensive ICP definition including: -- Firmographic profile (company size, industry, location) -- Behavioral profile (buying patterns, adoption style) -- Complete JTBD mapping (functional, emotional, social jobs) -- Top 5-7 pain points and specific needs -- Quantified impact metrics (cost of problem, value of solution) -- Decision-making process and key stakeholders -- Typical customer journey and timeline -- Go-to-market implications and messaging -- Disqualification criteria (who is NOT a good fit) -- High-value segment within ICP (ideal-of-the-ideal) - -## Framework -Based on Jobs to Be Done theory by Clayton Christensen and customer profiling methodology. Combines behavioral data with motivational insights to define actionable customer profiles. - -## Tips -- Use quantitative and qualitative data together -- Interview 10+ high-value customers for pattern identification -- Look for non-obvious demographic patterns (outliers can be high-value) -- Define both ideal ICP and acceptable secondary segments -- Revisit ICP quarterly as you gather more customer data -- Use ICP to evaluate all new sales opportunities -- Share ICP across entire organization (marketing, sales, product) -- Remember: ICP should drive focus, not exclude all others - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/.factory/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md b/.factory/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md deleted file mode 100644 index 34c8b07f..00000000 --- a/.factory/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem -description: >- - Ideas for affordances and signifiers based on a design problem. Use when the user needs a - product workflow for design & prototyping related to ideas for affordances and signifiers - based on a design problem. Trigger terms: ux, interaction-design, affordances, usability. ---- - - - -# Ideas for affordances and signifiers based on a design problem - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideas-for-affordances-and-signifiers-based-on-a-design-problem` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Ideas for affordances and signifiers based on a design problem**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_CHALLENGE}} - - -GOAL -Produce a high-quality deliverable for: Ideas for affordances and signifiers based on a design problem. -Success metric: -- Identifies key user interactions in the design challenge before proposing ideas. -- Produces at least 5 concrete ideas each for affordances, perceived affordances, and signifiers. -- Each idea includes a brief explanation tied to the challenge and UX impact. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DESIGN_CHALLENGE}}`; if context is incomplete, state assumptions explicitly. -- Start with a brief interaction analysis identifying main user functions/tasks. -- Generate at least 5 ideas in each category: affordances, perceived affordances, signifiers. -- For every idea, include a short explanation linking: - - the specific challenge friction/opportunity, - - how the idea guides user action or perception, - - expected UX improvement. -- Keep ideas practical, non-generic, and directly relevant to the described product context. - -FORMAT -Return exactly this structure: - - - -[Main user interactions/functions required by the challenge] - - - -1. [Affordance idea] - [Brief explanation] -2. [Affordance idea] - [Brief explanation] -3. [Affordance idea] - [Brief explanation] -4. [Affordance idea] - [Brief explanation] -5. [Affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Perceived affordance idea] - [Brief explanation] -2. [Perceived affordance idea] - [Brief explanation] -3. [Perceived affordance idea] - [Brief explanation] -4. [Perceived affordance idea] - [Brief explanation] -5. [Perceived affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Signifier idea] - [Brief explanation] -2. [Signifier idea] - [Brief explanation] -3. [Signifier idea] - [Brief explanation] -4. [Signifier idea] - [Brief explanation] -5. [Signifier idea] - [Brief explanation] -[Optional additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 5 ideas in any required category. -- Explanations are missing for one or more ideas. -- No interaction analysis is provided before idea lists. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-implementation-notes/SKILL.md b/.factory/skills/productize-implementation-notes/SKILL.md deleted file mode 100644 index 6da03e47..00000000 --- a/.factory/skills/productize-implementation-notes/SKILL.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: productize-implementation-notes -description: >- - Running implementation-notes protocol for spec-driven builds. Use when the user asks the - agent to maintain implementation-notes.md or implementation-notes.html with decisions, - deviations, tradeoffs, open questions, and verification while implementing a feature, fix, - or product slice. ---- - - - -# Implementation Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `implementation-notes` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence - -Use this skill when implementation work needs a durable notes artifact that keeps -the user in the loop without stopping progress for every ambiguity. - -This is not a verbose work log. It records the meaningful places where the spec -was interpreted, narrowed, changed, or found incomplete. - -## Activation - -Activate alongside `$tdd`, `$eng-review`, `$qa`, or `$verification` when the user -asks for any of: - -- `implementation-notes.md` -- `implementation-notes.html` -- running implementation notes -- decisions the spec did not cover -- deviations from the spec -- tradeoffs made during implementation -- open questions to confirm after implementation - -Do not ask whether to create the file if the user already requested it. Create or -update the requested file and keep working. - -## File Selection - -- Use the exact path and format the user requested. -- If the user asks for notes but does not name a file, use `implementation-notes.md`. -- If the user asks for HTML, use `implementation-notes.html`. -- If an implementation-notes file already exists for the current task, update it - instead of overwriting useful existing context. - -## Update Cadence - -1. Create the notes file before or during the first implementation decision. -2. Update it when the implementation makes a non-obvious choice, interprets an - ambiguous spec line, departs from the spec, accepts a tradeoff, discovers an - open question, or changes verification scope. -3. Batch small related choices into one entry instead of writing noisy micro-logs. -4. Before claiming completion, do a final pass that aligns notes with the actual - diff, verification evidence, and unresolved questions. - -## What To Capture - -### Design Decisions - -Choices made where the spec was ambiguous or silent. - -Each entry should include: - -- decision -- reason -- spec basis, or `unspecified` -- impact - -### Deviations - -Intentional departures from the spec. - -Each entry should include: - -- requested behavior -- implemented behavior -- reason -- impact -- whether user confirmation is needed - -### Tradeoffs - -Alternatives considered and why the chosen path is better for this slice. - -Each entry should include: - -- chosen option -- alternatives considered -- why chosen -- cost or downside accepted - -### Open Questions - -Questions the user may want to confirm or revise. - -Each entry should include: - -- question -- why it matters -- current default assumption -- status: `needs-review`, `accepted-risk`, `resolved`, or `deferred` - -### Verification - -Evidence that proves the implementation and the notes are current. - -Include: - -- commands or checks run -- result -- coverage gaps -- behavior not tested - -## What Not To Capture - -- Every file edit. -- Internal reasoning or chain-of-thought. -- Obvious implementation details already specified. -- Secrets, credentials, private customer data, or raw logs with sensitive content. -- Generic progress narration that does not help the user review decisions. - -## Markdown Template - -Use this structure for Markdown notes: - -```markdown -# Implementation Notes - -## Spec Reference -[Feature, ticket, prompt, or artifact being implemented.] - -## Summary -[One paragraph describing how the implementation interprets the spec.] - -## Design Decisions -| Decision | Reason | Spec basis | Impact | -|---|---|---|---| - -## Deviations -| Requested | Implemented | Why | Impact | Confirmation | -|---|---|---|---|---| - -## Tradeoffs -| Choice | Alternatives | Why this path | Downside | -|---|---|---|---| - -## Open Questions -| Question | Why it matters | Current assumption | Status | -|---|---|---|---| - -## Verification -| Check | Result | Notes | -|---|---|---| -``` - -## HTML Template Rules - -For `implementation-notes.html`, produce a single self-contained HTML file: - -- embedded CSS and JavaScript only -- no external assets or remote dependencies unless explicitly requested -- semantic headings and landmarks -- responsive layout -- decision cards or tables for scanability -- status chips for `needs-review`, `accepted-risk`, `resolved`, and `deferred` -- a clear verification section near the bottom -- optional filters, collapsible detail, or copy buttons only when they help review - -Recommended HTML sections: - -1. **Header**: spec reference, implementation status, last updated, owner if known. -2. **Decision Dashboard**: counts for decisions, deviations, tradeoffs, open questions. -3. **Design Decisions**: cards or table with reason, spec basis, and impact. -4. **Deviations**: requested vs implemented, why, impact, confirmation status. -5. **Tradeoffs**: comparison table with accepted downside. -6. **Open Questions**: status and current default assumption. -7. **Verification**: commands/checks, results, and gaps. - -## Route Internally - -- `$tdd` -- `$eng-review` -- `$qa` -- `$verification` -- `$docs` -- `$release` - -## Required Output - -Return: - -1. **Notes File**: path, format, and whether it was created or updated. -2. **Captured Decisions**: decisions, deviations, tradeoffs, and open questions added. -3. **Spec Impact**: what downstream product, design, eng, QA, release, docs, or DX work may change. -4. **Verification Linkage**: checks run, gaps, and whether the notes match the final implementation. -5. **Next Review**: user confirmations or gate follow-ups needed. diff --git a/.factory/skills/productize-industry-trend-strategy/SKILL.md b/.factory/skills/productize-industry-trend-strategy/SKILL.md deleted file mode 100644 index 28c42dff..00000000 --- a/.factory/skills/productize-industry-trend-strategy/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: productize-industry-trend-strategy -description: >- - Industry trend strategy. Use when the user needs a product workflow for product strategy - related to industry trend strategy. Trigger terms: strategy, competitive-analysis, - positioning, decision-making. ---- - - - -# Industry trend strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `industry-trend-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Industry trend strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INDUSTRY}} -- {{TREND}} -- {{COMPANY}} -- {{GOAL}} - - -GOAL -Produce a high-quality deliverable for: Industry trend strategy. -Success metric: -- Produces a grounded industry + trend analysis tied to company strengths and goal. -- Proposes at least three distinct strategies with actionable steps. -- Summarizes how strategies leverage strengths to achieve the goal. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{INDUSTRY}}`, `{{TREND}}`, `{{COMPANY}}`, and `{{GOAL}}`; if critical data is missing, state assumptions explicitly. -- Provide a concise industry + trend analysis and a focused company strengths assessment. -- Propose at least 3 distinct strategies aligned to strengths and goal. -- Each strategy must include name, description, alignment, contribution to goal, challenges, and action steps. -- Keep recommendations specific and actionable, not generic. - -FORMAT -Return exactly this structure: - - -[Industry + trend analysis and company strength assessment] - - - -1. [Strategy name] - - Description: [What it is] - - Alignment: [Company strengths leveraged] - - Contribution to goal: [How it advances the goal] - - Challenges: [Risks/obstacles] - - Action steps: [Concrete steps] -2. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -3. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -[Optional additional strategies] - - - -[Summary emphasizing how strategies leverage strengths to capitalize on the trend and achieve the goal] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 strategies are provided. -- Strategies lack alignment to company strengths or contribution to goal. -- Action steps are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md b/.factory/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md deleted file mode 100644 index 500376d5..00000000 --- a/.factory/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-influence-strategies-from-cialdini-s-7-principles -description: >- - Influence strategies from Cialdini's 7 principles. Use when the user needs a product - workflow for stakeholder management related to influence strategies from cialdini's 7 - principles. Trigger terms: influence, cialdini, stakeholder-management. ---- - - - -# Influence strategies from Cialdini's 7 principles - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `influence-strategies-from-cialdini-s-7-principles` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Influence strategies from Cialdini's 7 principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INFLUENCE_TARGET}} -- {{INFLUENCE_GOAL}} - - -GOAL -Produce a high-quality deliverable for: Influence strategies from Cialdini's 7 principles. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate influence ideas tailored to `{{INFLUENCE_TARGET}}` and `{{INFLUENCE_GOAL}}`. -- Provide at least one specific, actionable, ethical idea for each Cialdini principle: -- Reciprocity -- Liking -- Unity -- Authority -- Social Proof -- Consistency -- Scarcity -- For each idea, include a clear strategy and rationale tied to the target context and goal. -- Use professional, non-manipulative tactics that create value for both sides. - -FORMAT -Return exactly this structure: - - - -Name of the principle -Detailed description of the strategy or tactic -Explanation of why this idea would be effective for the given target and goal - -(Repeat this structure for each of the seven principles) - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Not all seven principles are covered, or principles are duplicated while another is missing. -- Strategies are generic, unethical/manipulative, or not tied to the target and goal. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-innovation-decision-making-heuristics/SKILL.md b/.factory/skills/productize-innovation-decision-making-heuristics/SKILL.md deleted file mode 100644 index 710886c0..00000000 --- a/.factory/skills/productize-innovation-decision-making-heuristics/SKILL.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -name: productize-innovation-decision-making-heuristics -description: >- - Design tailored decision-making heuristics for uncertain innovation work. Use when the user - needs simple decision rules for product bets, discovery, investment, pivot, prioritization, - or opportunity selection in noisy and changing contexts. ---- - - - -# Innovation Decision Making Heuristics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovation-decision-making-heuristics` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop - -Use this skill when a team needs a practical decision rule, not a one-off recommendation. -The output should help the team decide repeatedly under uncertainty while avoiding arbitrary -or off-the-shelf rules. - -## Decision-Making Principles - -- Heuristics are useful shortcuts when the environment is noisy, dynamic, uncertain, or - time-sensitive and more information does not necessarily clarify direction. -- Heuristics fail when applied blindly, when nuance matters, or when the environment is stable - enough for more complete analysis. -- Effective heuristics should come from the user's real business challenge, constraints, - evidence, and observed feedback. -- A good heuristic makes tradeoffs explicit: speed versus accuracy, exploration versus focus, - safety versus moonshot, and learning versus commitment. -- Heuristics must be reviewed and refined through practical experience. - -## Workflow - -1. Identify the recurring decision type and the context in which it appears. -2. Classify the environment: noisy/dynamic/uncertain, stable, time-sensitive, multi-factor, - politically loaded, or high-stakes irreversible. -3. Define what the heuristic should optimize: learning, speed, risk control, focus, upside, - user value, revenue, retention, or strategic fit. -4. Identify where naive heuristics could fail. -5. Create 3-5 tailored decision rules with explicit triggers and exceptions. -6. Add a feedback loop so the rule can improve after use. - -## Output Contract - -Return: - -```markdown -# Innovation Decision Making Heuristics - -## 1. Recurring Decision -Decision type: -Who decides: -Frequency: -Time pressure: -Stakes: - -## 2. Decision Environment -Context: -Noise / uncertainty: -Information quality: -Reversibility: -Stable analysis possible: - -## 3. What The Rules Should Optimize -Primary objective: -Secondary objective: -Tradeoff to accept: -Tradeoff to avoid: - -## 4. Heuristic Failure Risks -Where shortcuts help: -Where shortcuts fail: -Bias risks: -Escalation or sunk-cost risk: - -## 5. Tailored Decision Rules -Rule 1: -Use when: -Exception: -Evidence needed: - -Rule 2: -Use when: -Exception: -Evidence needed: - -Rule 3: -Use when: -Exception: -Evidence needed: - -## 6. Feedback And Refinement -Signal to track: -Review cadence: -Who updates the rule: -When to retire the rule: -``` - -## Failure Modes - -- Provides generic principles instead of concrete decision rules. -- Creates rules that ignore the user's actual uncertainty, constraints, and feedback loops. -- Treats heuristics as always good or always bad rather than context-dependent. -- Omits exceptions and review mechanisms. diff --git a/.factory/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md b/.factory/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md deleted file mode 100644 index fe4b11dc..00000000 --- a/.factory/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-project-parameters-and -description: >- - Innovative idea generation from project parameters and constraints. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, - product-management, osborn-checklist. ---- - - - -# Innovative idea generation from project parameters and constraints - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-project-parameters-and` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from project parameters and constraints**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_TYPE}} -- {{GOALS}} -- {{BUDGET}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from project parameters and constraints". -Success metric: -- Produces concrete, non-generic ideas that fit project type, goals, and budget. -- Uses structured creativity analysis (including Osborn checklist) to move beyond obvious solutions. -- Final ideas are immediately actionable with clear execution steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_TYPE}}`, `{{GOALS}}`, and `{{BUDGET}}`; if details are missing, state assumptions explicitly. -- Provide exactly 5 banal ideas to avoid and explain why each is weak. -- Define problem context including timeframe, target audience, and situation. -- Break down problem into objective, constraints, measurable success criteria, challenges, and deeper considerations. -- Analyze each chunk with explicit link to goals and budget feasibility. -- Include both creator and consumer perspectives. -- Apply Osborn checklist categories with project-relevant outputs: - - other uses, adaptations, modifications, magnification, minification, substitutions, rearrangements, reversals, combinations. -- Final ideas must be actionable for an individual, feasible under budget, and include step-by-step instructions plus application context. - -FORMAT -Return exactly this structure: - - - -1. [Banal idea] - [Why to avoid] -2. [Banal idea] - [Why to avoid] -3. [Banal idea] - [Why to avoid] -4. [Banal idea] - [Why to avoid] -5. [Banal idea] - [Why to avoid] - - - -[Clearly define the problem or situation] - - - -[Break down the problem into key aspects] - - - -[Provide in-depth analysis of each problem chunk] - - - -[Describe creator and consumer perspectives] - - - -- Other uses: [Ideas] -- Adaptations: [Ideas] -- Modifications: [Ideas] -- Magnification: [Ideas] -- Minification: [Ideas] -- Substitutions: [Ideas] -- Rearrangements: [Ideas] -- Reversals: [Ideas] -- Combinations: [Ideas] - - - -1. [Idea title] - - Specific guidance: [What to do] - - Steps: [Step-by-step] - - Where/how to apply: [Context/channel/tool] - - Budget fit: [How it stays within budget] -[Repeat for additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `banal_ideas` does not contain exactly 5 items. -- One or more Osborn checklist categories are missing. -- Final ideas are not actionable step-by-step or are not aligned to budget/goals. -- Output is generic or repeats clichรฉ ideas without meaningful differentiation. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md b/.factory/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 3a22d36f..00000000 --- a/.factory/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-structured-brainstorming -description: >- - Innovative idea generation from structured brainstorming techniques. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, - creativity, product-discovery, problem-solving. ---- - - - -# Innovative idea generation from structured brainstorming techniques - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from structured brainstorming techniques**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from structured brainstorming techniques". -Success metric: -- Produces a structured ideation session using free association, mind mapping, SCAMPER, and bias checks. -- Generates non-obvious, high-potential ideas grounded in the topic. -- Outputs clear top ideas with rationale and a concise synthesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run a complete structured ideation flow: - - free association (4-6 rounds), - - mind map (3-4 levels), - - SCAMPER exploration (2-3 rounds across shortlisted branches), - - bias check, - - top-idea selection and rationale. -- Avoid clichรฉd or overhyped ideas; prioritize specificity and novelty. -- Ensure top ideas are distinct from one another and clearly connected to generated branches. -- Keep outputs practical enough to be explored/prototyped next. - -FORMAT -Return exactly this structure: - - - -[4-6 rounds of free associations tied to `{{TOPIC}}`] - - - -[Mind map with 3-4 branching levels derived from free associations] - - - -1. [Branch] -2. [Branch] -3. [Branch] - - - -[2-3 rounds applying SCAMPER prompts to shortlisted branches] - - - -- Anchoring check: [Findings/adjustment] -- Status quo check: [Findings/adjustment] -- Groupthink check: [Findings/adjustment] - - - -1. [Idea 1] -2. [Idea 2] -3. [Idea 3] - - - -1. [Why idea 1 is powerful and non-obvious] -2. [Why idea 2 is powerful and non-obvious] -3. [Why idea 3 is powerful and non-obvious] - - - - -1. [Idea 1]: [Rationale] -2. [Idea 2]: [Rationale] -3. [Idea 3]: [Rationale] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `freeassociation` has fewer than 4 rounds or more than 6 rounds. -- `mindmap` does not show 3-4 levels of branching. -- `scamper` does not include at least 2 rounds. -- `top_ideas` does not contain exactly 3 distinct ideas. -- Rationales are generic and do not explain non-obvious value. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md b/.factory/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 0ccf894a..00000000 --- a/.factory/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -name: productize-innovative-product-ideas-from-structured-brainstorming -description: >- - Innovative product ideas from structured brainstorming. Use when the user needs a product - workflow for ideation & creativity related to innovative product ideas from structured - brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, - product-management. ---- - - - -# Innovative product ideas from structured brainstorming - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-product-ideas-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative product ideas from structured brainstorming**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative product ideas from structured brainstorming". -Success metric: -- Produces a complete structured brainstorming session from divergence to convergence. -- Generates non-obvious product ideas grounded in the topic and validated via bias checks. -- Returns exactly 3 top ideas with clear innovation rationale in abstract terms. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run all stages: free association, mind map, SCAMPER expansion, bias check, top-idea selection, summary. -- Avoid banal, overhyped, or clichรฉd outputs. -- Top ideas must be described abstractly; do not use specific tech buzzwords such as `AI`, `blockchain`, or `VR`. -- Ensure ideas are distinct and traceable to earlier brainstorming artifacts. - -FORMAT -Return exactly this structure: - - - - -1. [Word or phrase] -2. [Word or phrase] -... -[Total 8-10 items] - - - -[Topic] -- [Main branch 1] - - [Sub-branch 1a] - - [Sub-branch 1b] -- [Main branch 2] - - [Sub-branch 2a] - - [Sub-branch 2b] -- [Main branch 3] - - [Sub-branch 3a] - - [Sub-branch 3b] -[At least 3 main branches; each with 2-3 sub-branches] - - - -- Branch: [Name] - - Technique 1: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] - - Technique 2: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] -[Repeat for 3 branches] - - - -- Bias: [Name] - - Evidence in ideas: [How it appears] - - Countermeasure: [Concrete action] -[At least 1 bias] - - - -1. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -2. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -3. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] - - - -[Brief recap of process and why final ideas are stronger after SCAMPER and bias checks] - - - - -FAILURE -- Root tag `` or any required sub-tag is missing, malformed, or incomplete. -- `free_association` has fewer than 8 or more than 10 items. -- `mind_map` has fewer than 3 main branches or insufficient sub-branches. -- `scamper` does not cover 3 branches with 2 techniques each. -- `top_ideas` does not contain exactly 3 ideas. -- Top ideas include banned specific-technology terms (`AI`, `blockchain`, `VR`). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-interactive-intake-for-ost-inputs/SKILL.md b/.factory/skills/productize-interactive-intake-for-ost-inputs/SKILL.md deleted file mode 100644 index 7353afd5..00000000 --- a/.factory/skills/productize-interactive-intake-for-ost-inputs/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: productize-interactive-intake-for-ost-inputs -description: >- - Interactive intake for OST inputs. Use when the user needs a product workflow for user - research related to interactive intake for ost inputs. Trigger terms: user-research, ost, - continuous-discovery. ---- - - - -# Interactive intake for OST inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `interactive-intake-for-ost-inputs` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Interactive intake for OST inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Interactive intake for OST inputs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Act as an intake orchestrator for downstream OST inputs. -- Parse existing user-provided context first, then ask only missing critical questions. -- Collect and normalize exactly four variables: -- `{{business_outcome}}`: one concise, outcome-focused sentence (no solution wording). -- `{{journey_nodes_as_list}}`: JSON array of distinct journey moments (not features). -- `{{interview_transcripts_or_story_snippets}}`: markdown snippets with attribution and timestamps when available. -- `{{constraints_or_principles}}`: short markdown list/sentence or `None stated`. -- Apply quality guards: -- Reframe solution-flavored outcomes into measurable outcomes. -- Rephrase feature-like nodes into moments in time. -- Add minimal attribution labels when transcript context is sparse. -- Stop only when all four fields are present, clear, distinct, normalized, and confirmed. - -FORMAT -Return exactly this structure: - -{{business_outcome}}: [one concise, outcome-focused sentence] - -{{journey_nodes_as_list}}: ["[Moment 1]", "[Moment 2]", "[Moment 3]"] - -{{interview_transcripts_or_story_snippets}}: -[markdown transcript/snippets with speaker labels and timestamps if available] - -{{constraints_or_principles}}: -[short markdown list or sentence; if none provided, write "None stated"] - -FAILURE -- Any of the four required variables is missing or malformed. -- `{{business_outcome}}` is solution-flavored or not measurable/outcome-oriented. -- `{{journey_nodes_as_list}}` is not valid JSON array syntax or contains features instead of moments. -- Interview material lacks usable attribution/context when source data allows it. -- Constraints field is omitted instead of explicitly set to `None stated`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-lean-canvas/SKILL.md b/.factory/skills/productize-lean-canvas/SKILL.md deleted file mode 100644 index b3a18d33..00000000 --- a/.factory/skills/productize-lean-canvas/SKILL.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -name: productize-lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- - - - -# Lean Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `lean-canvas` -- **Lifecycle**: Think -- **Category**: Business Model -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.factory/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md b/.factory/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md deleted file mode 100644 index 672e4be9..00000000 --- a/.factory/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-limit-based-product-strategy-from-problem-to-execution-plan -description: >- - Limit-based product strategy from problem to execution plan. Use when the user needs a - product workflow for product strategy related to limit-based product strategy from problem - to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, - structured-thinking. ---- - - - -# Limit-based product strategy from problem to execution plan - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `limit-based-product-strategy-from-problem-to-execution-plan` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Limit-based product strategy from problem to execution plan**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Produce a high-quality deliverable for: Limit-based product strategy from problem to execution plan. -Success metric: -- Applies the full Limit-Based Product Thinking framework end-to-end. -- Produces concrete milestones, levers, assumptions, and a phased execution plan. -- Keeps outputs grounded in the provided problem statement. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM_STATEMENT}}`; if critical details are missing, state assumptions explicitly. -- Follow all 7 framework steps in order. -- Provide quantified convergence milestones at 10%, 25%, 50%, 75%, 90% with dates or triggers. -- Identify levers to accelerate convergence and explicitly name the top 1โ€“2 highest impact moves. -- List critical assumptions with validation methods. -- Provide a 3-phase plan (Foundation, Acceleration, Optimization) with timelines and resource guidance. - -FORMAT -Return exactly this structure: - - -1. Growth Variable: [Your identified variable] - -2. Limit State Description: - [Your vivid description of the fully mature state] - -3. Core Properties of the Limit: - [List of key features and interactions] - -4. Convergence Estimate: - [Growth curve and milestones] - -5. Acceleration Strategies: - [Prioritized list of levers to steepen the curve] - -6. Critical Assumptions: - [List of assumptions with validation methods] - -7. Product Vision and Execution: - Vision Statement: [One-sentence summary] - Roadmap: [Major milestones and timelines] - 3-Phase Plan: [Brief outline of each phase] - Resource Allocation: [Key recommendations] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Convergence milestones are missing required percentages or triggers/dates. -- Acceleration strategies lack prioritized top 1โ€“2 levers. -- Assumptions lack validation methods. -- 3-phase plan is missing or not sequenced. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md b/.factory/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md deleted file mode 100644 index 110f89a8..00000000 --- a/.factory/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: productize-low-frequency-to-power-user-transition-strategy -description: >- - Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow - for product strategy related to low-frequency-to-power-user transition strategy. Trigger - terms: product-strategy, engagement, activation, retention. ---- - - - -# Low-Frequency-to-Power-User Transition Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `low-frequency-to-power-user-transition-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Low-Frequency-to-Power-User Transition Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_DESCRIPTION}} -- {{CURRENT_USE_CASE}} -- {{TARGET_USE_CASE}} - - -GOAL -Produce a high-quality deliverable for: Low-Frequency-to-Power-User Transition Strategy. -Success metric: -- Produces a concrete transition plan from low-frequency to high-frequency usage. -- Aligns strategy to current and target use cases with explicit behavioral gaps. -- Includes metrics, timeline, and rollout/education plans grounded in the inputs. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_DESCRIPTION}}`, `{{CURRENT_USE_CASE}}`, and `{{TARGET_USE_CASE}}`; if information is missing, state assumptions explicitly. -- Identify the behavioral gap between current and target usage. -- Provide step-by-step transition plan, education/onboarding, and communication strategy. -- Include rollout plan, key metrics, and timeline for measurement. -- Keep recommendations specific and grounded in the provided context. - -FORMAT -Return exactly this structure: - - -1. Current Use Case Analysis: - [Provide a brief analysis of the current low-frequency use case] - -2. Target Use Case Analysis: - [Provide a brief analysis of the target high-frequency use case] - -3. User Behavior and Needs: - [Summarize key insights about user behavior and needs] - -4. Transition Strategy: - a. Feature Introduction Plan: - [Outline the step-by-step plan for introducing new features] - b. User Education and Onboarding: - [Describe the approach for educating users about the new use case] - c. Communication Strategy: - [Outline the key messages and channels for communicating the benefits] - d. Gradual Rollout Plan: - [Describe the approach for gradually introducing new functionality] - -5. Implementation and Measurement: - a. Key Metrics: - [List the primary metrics to track for measuring success] - b. Timeline: - [Provide a high-level timeline for implementation and evaluation] - c. Feedback and Iteration: - [Describe the plan for collecting user feedback and making improvements] - -6. Potential Challenges and Mitigation Strategies: - [Identify potential obstacles and propose solutions] - -7. Conclusion: - [Summarize the key points of the transition strategy and its potential impact] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Behavioral gap or barriers are not explicitly identified. -- Metrics or timeline are missing. -- Strategies are generic or not tied to the given use cases. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-managerial-finance-dcf/SKILL.md b/.factory/skills/productize-managerial-finance-dcf/SKILL.md deleted file mode 100644 index 6b191136..00000000 --- a/.factory/skills/productize-managerial-finance-dcf/SKILL.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -name: productize-managerial-finance-dcf -description: >- - Productize Finance engine for time value of money, DCF, NPV, IRR, payback, free cash flow, - terminal value, project valuation, mutually exclusive investments, and whether growth - creates or destroys value. ---- - - - -# Managerial Finance DCF - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `managerial-finance-dcf` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings - -## Purpose - -Core investment-decision skill for evaluating projects and cash-flow streams. -Use it when comparing investments, building free cash flow forecasts, calculating -NPV/IRR/payback, estimating terminal value, or judging whether growth creates value. - -## Core Formulas - -- `FV_t = C_0 * (1 + r)^t` -- `PV = C_t / (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(C_t / (1 + r)^t)` -- `NPV with TV = -I_0 + sum(FCF_t / (1 + r)^t) + TV_N / (1 + r)^N` -- `0 = -I_0 + sum(C_t / (1 + IRR)^t)` -- `Profitability Index = PV of Future Cash Flows / Initial Investment` -- `FCF = EBIT * (1 - T_c) + Depreciation - CapEx - Delta NWC` -- `NOPAT = EBIT * (1 - T_c)` -- `TV_N = FCF_{N+1} / (r - g)` with `r > g` -- `ROIC = NOPAT / Invested Capital` -- `Reinvestment Rate = (CapEx - Depreciation + Delta NWC) / NOPAT` -- `g = ROIC * Reinvestment Rate` - -## Decision Rules - -- Independent projects: accept if `NPV > 0`; reject if `NPV < 0`. -- Mutually exclusive projects: choose the highest NPV. -- IRR supports the decision, but warn when cash flows change sign more than once, - projects differ in scale or timing, or multiple/no real IRRs exist. -- Growth creates value only when `ROIC > WACC`; it destroys value when `ROIC < WACC`. - -## Required Functions - -Use `$finance-modeling-kernel` functions for PV/FV, streams, NPV, IRR, payback, -discounted payback, annuities, perpetuities, free cash flow, terminal value, -ROIC, reinvestment rate, and sustainable growth. - -## Required Validation - -- Warn if comparing undiscounted cash flows across time. -- Warn if terminal growth exceeds long-run economic growth. -- Reject `g >= r` in growing perpetuity. -- Warn if IRR conflicts with NPV. -- Warn if payback is used as the final decision rule. -- Warn if sunk costs, financing cash flows, non-incremental overhead, cannibalization, - or opportunity cost are mishandled. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Make NPV the primary investment decision rule. diff --git a/.factory/skills/productize-map-power-dynamics-before-meetings/SKILL.md b/.factory/skills/productize-map-power-dynamics-before-meetings/SKILL.md deleted file mode 100644 index 6bfe5f9f..00000000 --- a/.factory/skills/productize-map-power-dynamics-before-meetings/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-map-power-dynamics-before-meetings -description: >- - Map power dynamics before meetings. Use when the user needs a product workflow for - stakeholder management related to map power dynamics before meetings. Trigger terms: - stakeholders, power-dynamics, meetings, communication. ---- - - - -# Map power dynamics before meetings - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `map-power-dynamics-before-meetings` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Map power dynamics before meetings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DETAILS}} -- {{ATTENDEES_INFO}} - - -GOAL -Produce a high-quality deliverable for: "Map power dynamics before meetings". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{MEETING_DETAILS}}` and `{{ATTENDEES_INFO}}` to map meeting-specific power dynamics. -- Identify formal hierarchy, informal influence signals, alliances/conflicts, and each attendee's stake in outcomes. -- Rank attendees by influence in this meeting context. -- Identify decision-makers, influencers, power imbalances, and likely conflict points. -- Provide actionable strategies to navigate dynamics during the meeting. -- If information is insufficient for any claim, explicitly state the uncertainty. - -FORMAT -Return exactly this structure: - - - -[List attendees in order of influence, with brief notes on their power sources] - - - -[Bullet points of important observations about the power dynamics] - - - -[Bullet points of strategies to navigate the power dynamics effectively] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Influence ranking is not meeting-contextual or lacks power-source rationale. -- Recommendations are generic or not tied to identified dynamics/conflicts. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md b/.factory/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md deleted file mode 100644 index 1cb24d45..00000000 --- a/.factory/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-market-opportunities-from-jobs-to-be-done-market-canvas -description: >- - Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product - workflow for product strategy related to market opportunities from jobs-to-be-done market - canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, - product-strategy. ---- - - - -# Market opportunities from Jobs-to-be-Done market canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunities-from-jobs-to-be-done-market-canvas` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path - -Use this skill to run the Productize prompt contract for **Market opportunities from Jobs-to-be-Done market canvas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_OR_SERVICE}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Market opportunities from Jobs-to-be-Done market canvas. -Success metric: -- Guides the user through all 8 JTBD canvas steps with clear prompts. -- Keeps responses tied to provided `{{USER_INPUT}}` and the product context. -- Ends with a concise summary prompt that reflects the completed canvas. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_OR_SERVICE}}` and `{{USER_INPUT}}`; if context is missing, state assumptions explicitly. -- Ask for user input at each of the 8 JTBD canvas steps. -- Provide a brief explanation before each stepโ€™s prompt. -- Require the user to answer within the specified `` tags. -- End by requesting a `` that synthesizes the full canvas. -- Remind the user to use `{{USER_INPUT}}` when answering. - -FORMAT -Return exactly this structure: - - -[Prompt + explanation for Traditional Market Definition] - - - -[Prompt + explanation for Job Executor Determination] - - - -[Prompt + explanation for Abstracted Job Executor] - - - -[Prompt + explanation for Job Executor Documentation] - - - -[Prompt + explanation for Product Function Analysis] - - - -[Prompt + explanation for Complementary Product Analysis] - - - -[Prompt + explanation for Job Statement Abstraction] - - - -[Prompt + explanation for Final Job Documentation] - - - -[Prompt asking the user to summarize the completed canvas] - - -FAILURE -- Any required step tag in `FORMAT` is missing, malformed, or incomplete. -- Prompts do not request user responses within the correct `` tags. -- User is not reminded to use `{{USER_INPUT}}` for responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-market-opportunity/SKILL.md b/.factory/skills/productize-market-opportunity/SKILL.md deleted file mode 100644 index bf55ae97..00000000 --- a/.factory/skills/productize-market-opportunity/SKILL.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -name: productize-market-opportunity -description: >- - Identify, compare, and choose market opportunities for a venture, product, technology, or - innovation. Use when a founder, entrepreneur, product team, or innovator is choosing which - market to enter, picking a primary customer segment, evaluating whether a technology has - better use cases, deciding whether to pivot, comparing growth options, framing a venture for - investors, or asking variants of "which market should I target", "is this the right - opportunity", "where should I focus", "should I pivot", or "what else could this be used - for". Produces filled-in opportunity canvases for the Market Opportunity Set, Attractiveness - Map, Focus Portfolio Map, and Focus Strategy. Default to this skill when the question is - where to play rather than how to play. ---- - - - -# Market Opportunity - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunity` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market Opportunity venture brief with target segment, wedge, assumptions, and validation path - -Create the complete four-part market opportunity artifact set for choosing where a -venture, technology, product, or innovation should play. - -Use neutral terms such as `canvas`, `opportunity artifact`, `strategy surface`, or the -artifact names below. - -## Argument Hint - -`` - -## Usage - -```text -/market-opportunity $ARGUMENTS -``` - -## Required Artifacts - -For any complete request, create all four artifacts unless the user explicitly asks for -only one: - -1. **Opportunity Overview Canvas**: the three-part overview with opportunity set, - attractiveness map, and focus portfolio map. -2. **Opportunity Set Builder**: abilities -> applications -> customers -> market - opportunities. -3. **Attractiveness Evaluator**: potential and challenge ratings for each market - opportunity. -4. **Focus Portfolio Planner**: primary market opportunity, backup options, growth - options, and pursue/keep/store decisions. - -Load `references/canonical-canvases.md` before creating blank templates, filled -templates, printable layouts, or tables. It defines the exact fields and structure. - -Load `references/rating-and-decision-rules.md` before rating opportunities, -classifying map zones, or recommending primary, backup, and growth options. - -Load `references/output-formats.md` when the user asks for Markdown, HTML, PDF, -slides, visual canvases, or printable templates. - -## Workflow - -### 1. Establish the Input Mode - -Determine whether the user wants: - -- **Blank canvas set**: empty structured artifacts for a team to fill in. -- **Filled canvas set**: completed artifacts from a venture/product/technology idea. -- **Opportunity review**: critique or improve an existing opportunity set. -- **Strategy decision**: choose the primary opportunity and portfolio options. -- **Printable artifact**: create visual HTML/PDF/slide-ready canvases. - -If context is missing, ask only for the smallest useful missing piece: - -- The venture, product, technology, or core ability. -- Candidate applications. -- Candidate customer groups. -- Existing evidence for demand, market size, economics, implementation, timing, and risks. - -### 2. Generate the Market Opportunity Set - -Identify the venture's core abilities or technological elements first. Describe them -independent of the envisioned product. - -Then generate combinations: - -```text -market opportunity = application + customer segment -``` - -Segment customers precisely. Avoid broad labels like "enterprises" or "consumers" -unless the user has no better information. - -### 3. Evaluate Attractiveness - -For each market opportunity, rate: - -- **Potential** - - Compelling reason to buy. - - Market volume. - - Economic viability. -- **Challenge** - - Implementation obstacles. - - Time to revenue. - - External risks. - -Use the four-level rating scale: - -```text -Low / Mid / High / Super High -``` - -Then place each opportunity on the attractiveness map: - -- **Gold Mine** -- **Quick Win** -- **Moon Shot** -- **Questionable** - -### 4. Design the Focus Portfolio - -Choose one **Primary Market Opportunity** based on attractiveness and strategic fit. - -For other attractive opportunities, assess relatedness to the primary opportunity: - -- **Product relatedness**: shared technological competences, required resources, - and necessary networks. -- **Market relatedness**: shared customer values and benefits, sales channels, and - word-of-mouth paths. - -Classify each option: - -- **Growth Option**: attractive and useful for creating additional value. -- **Backup Option**: attractive and does not share major risks with the primary path. -- **Storage**: documented but not worth active preservation now. - -Make one of three action decisions for each option: - -- Pursue now. -- Keep open. -- Place in storage. - -The final strategy must keep at least one credible backup option and one credible -growth option open unless the available evidence makes that impossible. If impossible, -say what evidence or opportunity generation is missing. - -### 5. Tie Strategy to Execution - -For completed strategy outputs, include implications for: - -- Product and technology modularity. -- IP and defensibility. -- Hiring and capability development. -- Stakeholder and investor alignment. -- Brand and market communication. -- Experiments, assumptions, and learning loops. -- Business Model Canvas, Value Proposition Canvas, and Lean Startup integration when - the user asks for execution planning. - -## Output Rules - -- Preserve the canonical field names and rating scales from the reference files. -- Do not collapse the framework into SWOT, generic market sizing, or a feature - prioritization matrix. -- Be explicit about assumptions and evidence gaps. -- Use tables for editable outputs. -- For visual outputs, use the same four-artifact structure and neutral artifact titles. -- Do not copy long passages from source PDFs. Use the exact operational labels and - schemas, with original wording for explanations and recommendations. diff --git a/.factory/skills/productize-market-opportunity/references/canonical-canvases.md b/.factory/skills/productize-market-opportunity/references/canonical-canvases.md deleted file mode 100644 index a3c436db..00000000 --- a/.factory/skills/productize-market-opportunity/references/canonical-canvases.md +++ /dev/null @@ -1,234 +0,0 @@ -# Canonical Market Opportunity Canvases - -Use these four canvases as the canonical output surfaces. Use neutral artifact names in -user-facing output. - -## 1. Opportunity Overview Canvas - -Purpose: show the entire flow from opportunity generation to attractiveness placement -to focus portfolio decision. - -Required fields: - -- Name. -- Date. -- Title: `Market Opportunity Overview`. -- Market opportunity definition: `application + customer`. -- Left panel: **Market Opportunity Set**. -- Middle panel: **Attractiveness Map**. -- Right panel: **Focus Portfolio Map**. - -### Market Opportunity Set Panel - -Contains market opportunity cards generated from: - -```text -application + customer = market opportunity -``` - -Each card should have: - -| Field | Description | -|---|---| -| ID | Short stable label such as MO-1, MO-2, MO-3 | -| Application | What the core ability enables | -| Customer segment | Who needs that application | -| Market opportunity | Combined application + customer | - -### Attractiveness Map Panel - -Axes: - -| Axis | Direction | Rating Levels | -|---|---|---| -| Potential | vertical | Low, Mid, High, Super High | -| Challenge | horizontal | Low, Mid, High, Super High | - -Zones: - -| Zone | Meaning | -|---|---| -| Gold Mine | High potential with relatively low challenge | -| Quick Win | Lower potential with relatively low challenge | -| Moon Shot | High potential with high challenge | -| Questionable | Lower potential with high challenge | - -### Focus Portfolio Map Panel - -Nested decision areas: - -| Area | Meaning | -|---|---| -| Pursue now | Active focus or active parallel pursuit | -| Keep open | Preserve option value without fully committing | -| Place in storage | Document but do not actively preserve now | - -Cards placed here must identify whether they are primary, backup, growth, or storage -options. - -## 2. Opportunity Set Builder - -Purpose: generate market opportunities by combining core abilities, applications, and -customer segments. - -Required fields: - -- Name. -- Date. -- Title: `Generate Your Market Opportunity Set`. -- Core abilities or technological elements. -- Applications. -- Customers. -- Market opportunities. - -### Core Abilities Table - -List the venture's core abilities or technological elements. Characterize each by -function and properties, independent from the envisioned product. - -| Ability ID | Core Ability or Technological Element | Function | Key Properties | Evidence / Notes | -|---|---|---|---|---| -| A1 | | | | | -| A2 | | | | | -| A3 | | | | | -| A4 | | | | | - -### Market Opportunity Generation Table - -Use each row to combine an application with a customer segment. - -| Opportunity ID | Ability ID(s) | Application | Customer Segment | Finer Customer Segmentation | Market Opportunity | -|---|---|---|---|---|---| -| MO-1 | | | | | | -| MO-2 | | | | | | -| MO-3 | | | | | | - -Generation prompts: - -- Which applications can the core abilities offer? -- Which customers may need each application? -- Can the customer group be segmented more precisely? -- Which combinations should be evaluated next? - -## 3. Attractiveness Evaluator - -Purpose: evaluate each market opportunity by potential and challenge, then place it -on the attractiveness map. - -Required fields: - -- Name. -- Date. -- Title: `Evaluate Market Opportunity Attractiveness`. -- Market Opportunity. -- Potential. -- Challenge. -- Overall Potential. -- Overall Challenge. -- Attractiveness Map zone. - -Use this canvas once for every market opportunity being evaluated. - -### Potential Ratings - -| Potential Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Compelling Reason to Buy | Unmet need; effective solution; better than current solutions | Low / Mid / High / Super High | | -| Market Volume | Current market size; expected growth | Low / Mid / High / Super High | | -| Economic Viability | Margins (value vs. cost); customers' ability to pay; customer stickiness | Low / Mid / High / Super High | | - -### Challenge Ratings - -| Challenge Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Implementation Obstacles | Product development difficulties; sales and distribution difficulties; funding challenges | Low / Mid / High / Super High | | -| Time to Revenue | Development time; time between product and market readiness; length of sales cycle | Low / Mid / High / Super High | | -| External Risks | Competitive threat; third-party dependencies; barriers to adoption | Low / Mid / High / Super High | | - -### Overall Placement - -| Market Opportunity | Overall Potential | Overall Challenge | Map Zone | Rationale | -|---|---|---|---|---| -| | Low / Mid / High / Super High | Low / Mid / High / Super High | Gold Mine / Quick Win / Moon Shot / Questionable | | - -## 4. Focus Portfolio Planner - -Purpose: design the focus strategy around one primary market opportunity while -preserving backup and growth options. - -Required fields: - -- Name. -- Date. -- Title: `Design Your Focus Strategy`. -- Primary Market Opportunity. -- Other attractive market opportunities. -- Product relatedness. -- Market relatedness. -- Suitable as backup option. -- Suitable as growth option. -- Action decision: pursue now, keep open, or place in storage. - -### Step I: Choose Primary Market Opportunity - -Choose the primary market opportunity based on the attractiveness map. - -| Primary Market Opportunity | Attractiveness Map Position | Why This Is Primary | Main Evidence | Main Risks | -|---|---|---|---|---| -| | | | | | - -### Step II: Examine Other Attractive Opportunities - -For each other attractive market opportunity, compare it with the primary opportunity. - -| Option ID | Market Opportunity | Product Relatedness | Product Relatedness Rationale | Market Relatedness | Market Relatedness Rationale | Risk Overlap With Primary | -|---|---|---|---|---|---|---| -| MO-2 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-3 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-4 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | - -Product relatedness asks how much the products share: - -- Technological competences. -- Required resources. -- Necessary networks. - -Market relatedness asks how much the customers share: - -- Values and benefits. -- Sales channels. -- Word-of-mouth paths. - -### Step III: Classify and Decide - -Use this table to mark whether each option is suitable as backup, growth, both, or -neither, then decide what to do with it. - -| Option ID | Market Opportunity | Backup Option? | Growth Option? | Action | Rationale | -|---|---|---|---|---|---| -| MO-2 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-3 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-4 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | - -Definitions: - -- **Backup Option**: an attractive market opportunity that does not share major risks - with the primary market opportunity and can support a change in direction. -- **Growth Option**: an attractive market opportunity that can create additional value - if the primary opportunity succeeds. - -Strategy rule: - -- Keep at least one Backup Option open. -- Keep at least one Growth Option open. -- Decide whether any option is worth pursuing now. -- Place the rest in storage. - -### Final Focus Strategy Summary - -| Category | Market Opportunity | Decision | Why | -|---|---|---|---| -| Primary | | Pursue now | | -| Backup | | Keep open / Pursue now | | -| Growth | | Keep open / Pursue now | | -| Storage | | Place in storage | | diff --git a/.factory/skills/productize-market-opportunity/references/output-formats.md b/.factory/skills/productize-market-opportunity/references/output-formats.md deleted file mode 100644 index ee145a61..00000000 --- a/.factory/skills/productize-market-opportunity/references/output-formats.md +++ /dev/null @@ -1,143 +0,0 @@ -# Output Formats - -Use the same canonical four-artifact structure in every format. Use neutral artifact -names in titles and headings. - -## Markdown Blank Canvas Set - -Use when the user wants editable text tables. - -Required sections: - -```markdown -# Market Opportunity - -## 1. Opportunity Overview Canvas -[overview tables] - -## 2. Opportunity Set Builder -[blank abilities and opportunity generation tables] - -## 3. Attractiveness Evaluator -[one blank evaluator per opportunity, or reusable blank evaluator] - -## 4. Focus Portfolio Planner -[blank primary, relatedness, backup/growth, and action decision tables] -``` - -## Markdown Filled Canvas Set - -Use when the user provides a venture, technology, product, or opportunity set. - -Required sections: - -```markdown -# Market Opportunity: [Venture/Product] - -## 1. Opportunity Overview Canvas -- Market opportunity cards. -- Attractiveness placements. -- Focus portfolio decisions. - -## 2. Opportunity Set Builder -- Core abilities. -- Applications. -- Customer segments. -- Generated market opportunities. - -## 3. Attractiveness Evaluator -- One evaluation table per selected market opportunity. -- Overall potential, overall challenge, and map zone. - -## 4. Focus Portfolio Planner -- Primary market opportunity. -- Option comparison by product and market relatedness. -- Backup/growth classification. -- Pursue now / keep open / place in storage decisions. - -## Strategy Implications -- Product/technology modularity. -- IP and defensibility. -- Hiring/capability needs. -- Stakeholder and investor alignment. -- Brand and communication implications. -- Experiments and next evidence to collect. -``` - -## Visual or Printable Canvas - -Use when the user asks for printable templates, visual canvases, an HTML file, a PDF, -or a slide-ready output. - -Requirements: - -- Produce four separate pages or sections. -- Preserve the same layout logic: - - Overview: three panels side by side. - - Opportunity Set Builder: abilities at top; applications and customers below. - - Attractiveness Evaluator: potential on left, challenge on right, overall ratings at - the bottom. - - Focus Portfolio Planner: primary opportunity at top, option columns below, relatedness - rows, backup/growth rows, action rows at bottom. -- Use neutral artifact titles. -- Include `Name` and `Date` fields when producing a printable artifact. -- Include editable blank spaces or filled content depending on the requested mode. - -Recommended visual names: - -| Original Function | Use This Title | -|---|---| -| Full opportunity overview | Market Opportunity Overview | -| Generate opportunity set | Opportunity Set Builder | -| Evaluate attractiveness | Market Opportunity Attractiveness | -| Design focus strategy | Focus Strategy Planner | - -## Compact Decision Memo - -Use when the user wants a concise strategic answer rather than the full canvas set. - -Required sections: - -```markdown -## Recommendation -[Primary market opportunity and why] - -## Opportunity Portfolio -| Category | Opportunity | Decision | Why | - -## Key Ratings -| Opportunity | Potential | Challenge | Zone | - -## Risks and Open Assumptions -[Most important evidence gaps] - -## Next Tests -[Lean experiments or research needed] -``` - -## Spreadsheet-Friendly Format - -Use when the user wants to paste into Sheets/Excel. - -Create four CSV-style tables: - -1. `opportunity_set` -2. `attractiveness_ratings` -3. `map_placements` -4. `focus_portfolio` - -Minimum columns: - -```text -opportunity_set: -opportunity_id,ability_ids,application,customer_segment,finer_segment,market_opportunity - -attractiveness_ratings: -opportunity_id,potential_compelling_reason,potential_market_volume,potential_economic_viability,overall_potential,challenge_implementation,challenge_time_to_revenue,challenge_external_risks,overall_challenge,evidence_notes - -map_placements: -opportunity_id,overall_potential,overall_challenge,map_zone - -focus_portfolio: -opportunity_id,role,product_relatedness,market_relatedness,risk_overlap,backup_option,growth_option,action,rationale -``` diff --git a/.factory/skills/productize-market-opportunity/references/rating-and-decision-rules.md b/.factory/skills/productize-market-opportunity/references/rating-and-decision-rules.md deleted file mode 100644 index fdfe3093..00000000 --- a/.factory/skills/productize-market-opportunity/references/rating-and-decision-rules.md +++ /dev/null @@ -1,250 +0,0 @@ -# Rating and Decision Rules - -Use these rules to keep opportunity ratings consistent. - -## Rating Scale - -Use only these four levels: - -```text -Low / Mid / High / Super High -``` - -For challenge dimensions, higher means more difficult, slower, riskier, or more -resource-intensive. Low challenge is good. - -## Potential Ratings - -### Compelling Reason to Buy - -Rate based on: - -- Strength of unmet need. -- Whether the solution effectively addresses the need. -- Whether it is better than current alternatives. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak pain, unclear need, or little advantage over alternatives | -| Mid | Recognizable need but limited urgency or differentiation | -| High | Clear need, strong solution fit, meaningful advantage | -| Super High | Urgent need, strong willingness to switch or buy, clear superiority | - -### Market Volume - -Rate based on: - -- Current market size. -- Expected growth. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Small or shrinking reachable market | -| Mid | Meaningful niche or uncertain growth | -| High | Large reachable market or strong growth | -| Super High | Very large market with strong growth and credible reach | - -### Economic Viability - -Rate based on: - -- Margins: value created versus cost to deliver. -- Customers' ability to pay. -- Customer stickiness. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak margins, low willingness or ability to pay, low retention potential | -| Mid | Economics may work but are not yet proven | -| High | Attractive value/cost relationship and credible willingness to pay | -| Super High | Strong margins, high willingness to pay, strong retention or lock-in | - -## Challenge Ratings - -### Implementation Obstacles - -Rate based on: - -- Product development difficulties. -- Sales and distribution difficulties. -- Funding challenges. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Straightforward product, go-to-market, and funding path | -| Mid | Some execution difficulty, but manageable | -| High | Significant product, distribution, or funding obstacles | -| Super High | Very difficult execution path or major resource gap | - -### Time to Revenue - -Rate based on: - -- Development time. -- Gap between product readiness and market readiness. -- Length of sales cycle. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Revenue can plausibly arrive quickly | -| Mid | Moderate path to revenue | -| High | Long development, readiness, or sales cycle | -| Super High | Very long or uncertain time to revenue | - -### External Risks - -Rate based on: - -- Competitive threat. -- Third-party dependencies. -- Barriers to adoption. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Limited external risk or manageable dependencies | -| Mid | Some competitive, dependency, or adoption risk | -| High | Serious external risks that could block progress | -| Super High | External risks may dominate the opportunity | - -## Overall Potential and Challenge - -Do not compute mechanically unless the user asks for numeric scoring. Use evidence and -judgment. - -Default aggregation: - -- Overall Potential should reflect the weakest critical potential dimension. A huge - market is not enough if there is no compelling reason to buy. -- Overall Challenge should reflect the hardest blocking challenge. A simple build is - not enough if revenue requires a multi-year sales cycle. - -If using numeric support: - -```text -Low = 1 -Mid = 2 -High = 3 -Super High = 4 -``` - -Use the rounded average as a starting point, then adjust for blockers and explain the -adjustment. - -## Attractiveness Map Zone Rules - -| Overall Potential | Overall Challenge | Zone | -|---|---|---| -| High or Super High | Low or Mid | Gold Mine | -| Low or Mid | Low or Mid | Quick Win | -| High or Super High | High or Super High | Moon Shot | -| Low or Mid | High or Super High | Questionable | - -Interpretation: - -- **Gold Mine**: strongest candidate for primary focus. -- **Quick Win**: potentially useful for learning, early traction, or stepping stones. -- **Moon Shot**: valuable but difficult; may require capital, patience, or unique assets. -- **Questionable**: weak candidate unless strategic reasons or new evidence change the view. - -## Primary Market Opportunity Rules - -Select the primary opportunity by weighing: - -- Attractiveness map zone. -- Strength of evidence. -- Founder/team fit. -- Ability to test assumptions. -- Strategic control and defensibility. -- Fit with resource constraints. - -Default preference: - -1. Gold Mine with strong evidence. -2. Gold Mine with evidence gaps but testable assumptions. -3. Quick Win if it creates learning, revenue, or capability for a larger path. -4. Moon Shot only if the upside is large enough and the team has unusual advantages. -5. Questionable only if the user explicitly has strategic reasons. - -## Backup Option Rules - -A backup option should be attractive and should not share major risks with the primary -opportunity. - -Good backup options often differ on: - -- Customer segment. -- Sales channel. -- Adoption barrier. -- Regulatory pathway. -- Revenue model. -- Critical dependency. - -Do not label an option as backup merely because it is related. If it fails for the same -reason the primary fails, it is not a useful backup. - -## Growth Option Rules - -A growth option should be attractive and should let the venture create additional value -after or alongside the primary opportunity. - -Good growth options often share: - -- Technology. -- Capabilities. -- Customer relationships. -- Distribution. -- Brand credibility. -- Data or network effects. - -High relatedness makes a growth option more plausible. Very low relatedness usually -means the opportunity is diversification, not a near-term growth option. - -## Action Decision Rules - -### Pursue Now - -Use when: - -- The option is primary, or -- The option is highly attractive, resources permit parallel pursuit, and pursuing it - does not dilute the primary focus. - -### Keep Open - -Use when: - -- The option has strategic value as backup or growth. -- The cost of preserving it is modest. -- It requires monitoring, lightweight experiments, modular design choices, IP claims, - partner conversations, or relationship maintenance. - -### Place in Storage - -Use when: - -- The option is not attractive enough now. -- The opportunity is too unrelated or costly to preserve. -- Evidence is too weak. -- It is worth remembering but not worth spending active effort on. - -## Evidence Discipline - -For each rating, distinguish: - -- Evidence: facts, interviews, data, observed behavior, signed interest, market numbers. -- Assumptions: plausible but unvalidated beliefs. -- Unknowns: missing information that could change the rating. - -When evidence is weak, phrase the output as a hypothesis and propose the next test. diff --git a/.factory/skills/productize-market-orientation-audit/SKILL.md b/.factory/skills/productize-market-orientation-audit/SKILL.md deleted file mode 100644 index 914f16eb..00000000 --- a/.factory/skills/productize-market-orientation-audit/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: productize-market-orientation-audit -description: >- - Audit whether an organization is truly market oriented using intelligence generation, - intelligence dissemination, and responsiveness. Use for customer-centricity, marketing - culture, organizational diagnosis, market sensing, and scorecard-based improvement plans. ---- - - - -# Market Orientation Audit - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-orientation-audit` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user wants to diagnose how well an organization senses markets, shares customer/competitor insight internally, and acts on that insight. - -Do not use it for brand health, campaign evaluation, or product-market fit unless the question is specifically about organizational market orientation. - -## Core Model - -Market orientation is an organization-wide culture and operating system for creating customer value. It has three dimensions: - -- **Intelligence generation**: how the organization detects customer, competitor, collaborator, technology, and regulatory changes. -- **Intelligence dissemination**: how quickly and effectively insight spreads across functions. -- **Responsiveness**: how fast and well the organization acts on market intelligence. - -## Scorecard - -Use a 1-5 scale: - -- 5 = Strongly agree -- 4 = Agree -- 3 = Neither agree nor disagree -- 2 = Disagree -- 1 = Strongly disagree - -Each dimension has 8 items. Dimension scoring: - -- 29-40 = High -- 20-28 = Moderate -- 8-19 = Low - -Total scoring: - -- 86-120 = High -- 60-85 = Moderate -- 24-59 = Low - -### Intelligence Generation - -1. We have interdepartmental meetings at least once a quarter to discuss market trends and developments. -2. We are quick to detect fundamental shifts in our industry, such as competition, technology, or regulation. -3. We periodically review the likely effect of environmental changes on customers. -4. We are fast to detect changes in customer product and service preferences. -5. People discuss customers' future needs with other functions or departments. -6. We do a lot of in-house market research. -7. We survey key customers at least once a year to assess product and service quality. -8. We meet key clients at least once a year to learn what products or services they will need in the future. - -### Intelligence Dissemination - -1. When something important happens to a major customer or market, the whole business knows quickly. -2. When one department learns something important about competitors, it quickly alerts other departments. -3. We would never ignore changes in customer product or service needs. -4. When customers want a product or service modification, involved teams make concerted efforts to respond. -5. We periodically review product or service development to ensure it aligns with key customer needs. -6. We have communication systems that speed dissemination of important customer-related information. -7. All functions and departments are responsive to each other's needs and requests. -8. When a customer complains or gives feedback, we quickly share it with anyone who can act on it. - -### Responsiveness - -1. It takes very little time to decide how to respond to competitor product or service changes. -2. We can implement new ideas, marketing plans, product redesigns, or service enhancements in a timely fashion. -3. Several functions periodically plan responses to changes in the business environment. -4. If a major competitor aggressively targeted a key customer, we would consider a response immediately. -5. We quickly act on customer complaints and feedback. -6. Customer-facing employees have latitude to solve customer problems without excessive red tape. -7. People here tend to talk more about opportunities than problems. -8. When we see a new opportunity to create customer value, we act quickly. - -## Workflow - -1. Collect scores from the user or run a facilitated self-assessment. -2. Compute dimension totals and total score. -3. Identify the weakest dimension and the lowest individual items. -4. Diagnose root causes across incentives, structure, tooling, decision rights, data access, rituals, and culture. -5. Translate findings into operating changes, not just research recommendations. -6. Define a 30/60/90-day improvement plan and measurement cadence. - -## Output - -Return: - -- **Score Summary**: dimension scores, total score, high/moderate/low rating. -- **Pattern Diagnosis**: what the scores imply about market sensing, sharing, and action. -- **Lowest Items**: the specific behaviors causing the largest gap. -- **Organizational Hurdles**: structure, incentives, data, rituals, authority, culture. -- **Improvement Plan**: 30/60/90-day actions. -- **Operating Metrics**: indicators to track improvement. - -## Quality Bar - -- Do not equate customer-facing friendliness with market orientation. -- Treat market orientation as cross-functional. -- Separate collecting insight from acting on insight. -- Recommend concrete operating changes, not generic "talk to customers more" advice. diff --git a/.factory/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md b/.factory/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md deleted file mode 100644 index ca888dbb..00000000 --- a/.factory/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: productize-market-requirements-from-strategic-market-inputs -description: >- - Market requirements from strategic market inputs. Use when the user needs a product workflow - for product strategy related to market requirements from strategic market inputs. Trigger - terms: product-management, market-research, strategy, MRD. ---- - - - -# Market requirements from strategic market inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-requirements-from-strategic-market-inputs` -- **Lifecycle**: Strategize -- **Category**: Discovery -- **Primary artifact**: Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Market requirements from strategic market inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MARKET_INDUSTRY}} -- {{PROBLEM_UNMET_NEED}} -- {{TARGET_USER_BUYER}} -- {{CURRENT_ALTERNATIVES}} -- {{COMPANY_ROLE_VISION_ADVANTAGE}} -- {{EXTERNAL_FACTORS}} -- {{OUTPUT_REQUEST}} - - -GOAL -Produce a high-quality deliverable for: Market requirements from strategic market inputs. -Success metric: -- Gathers required MRD inputs via a structured question flow. -- Produces decision-ready MRD sections only after the user confirms โ€œReady to draft.โ€ -- Keeps analysis concise, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; ask one question at a time until the user says **โ€œReady to draft.โ€** -- Do not draft any MRD section before the user explicitly says **โ€œReady to draft.โ€** -- After the user selects the output (Aโ€“D), produce that section only and pause for feedback. -- Use links for citations; state assumptions explicitly. -- No emojis. No JSON output. - -FORMAT -Return exactly this structure: - - -Letโ€™s co-create a Market Requirements Document. Iโ€™ll ask a few questions to gather context and then generate a draft. First up: What market or industry are you exploring? - - - -[Your single next question based on the most recent answer] - - -[When user says โ€œReady to draft,โ€ respond with exactly one of the requested MRD sections using the MRD Output Format headings.] - -FAILURE -- Output drafts MRD sections before user says โ€œReady to draft.โ€ -- More than one question is asked at a time. -- Output does not follow the selected section from Aโ€“D. -- Missing citations/assumptions where needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-market-sizing/SKILL.md b/.factory/skills/productize-market-sizing/SKILL.md deleted file mode 100644 index 6467fec0..00000000 --- a/.factory/skills/productize-market-sizing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, - market-entry upside, or investor-ready opportunity size. ---- - - - -# Market Sizing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-sizing` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.factory/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md b/.factory/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md deleted file mode 100644 index be955241..00000000 --- a/.factory/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: productize-mece-analysis-and-logical-tree-from-list-items -description: >- - MECE analysis and logical tree from list items. Use when the user needs a product workflow - for decision making related to mece analysis and logical tree from list items. Trigger - terms: pm, decision-making, mece, structured-thinking, frameworks. ---- - - - -# MECE analysis and logical tree from list items - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `mece-analysis-and-logical-tree-from-list-items` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **MECE analysis and logical tree from list items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{LIST_OF_ITEMS}} - - -GOAL -Evaluate `LIST_OF_ITEMS` for MECE quality and produce a logical tree that resolves overlaps/gaps. -Success metric: -- Clearly assesses mutual exclusivity and collective exhaustiveness. -- Identifies concrete overlaps and coverage gaps (if any). -- Produces a coherent tree structure reflecting corrected grouping logic. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Test pairwise overlap (mutual exclusivity). - 2. Test coverage gaps (collective exhaustiveness). - 3. Propose corrected structure and hierarchy. -- Keep conclusions grounded in the provided list; avoid unrelated frameworks unless necessary. -- If ambiguity exists in item definitions, state assumptions explicitly. -- Provide concise rationale, not hidden/internal chain-of-thought. - -FORMAT -Return exactly this structure: - - - -[State whether items are mutually exclusive, with specific overlap examples where relevant] - - -[State whether items are collectively exhaustive, with specific gap examples where relevant] - - -[Concise list of overlap issues and/or coverage gaps] - - - - -[MECE status: Fully MECE | Not MECE | Partially MECE] - -[Hierarchical tree showing corrected structure and item placement] - - - -FAILURE -- Required schema sections are missing or malformed. -- Mutual exclusivity or collective exhaustiveness assessment is absent. -- Logical tree is missing, unclear, or inconsistent with analysis findings. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md b/.factory/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md deleted file mode 100644 index 917e0acf..00000000 --- a/.factory/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: productize-meeting-agendas-from-meeting-descriptions -description: >- - Meeting agendas from meeting descriptions. Use when the user needs a product workflow for - project management related to meeting agendas from meeting descriptions. Trigger terms: - meetings, facilitation, planning, productivity. ---- - - - -# Meeting agendas from meeting descriptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-agendas-from-meeting-descriptions` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Meeting agendas from meeting descriptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DESCRIPTION}} - - -GOAL -Produce a high-quality deliverable for: "Meeting agendas from meeting descriptions". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a meeting preparation output from `{{MEETING_DESCRIPTION}}` that includes: -- A clear purpose statement for the meeting. -- A structured agenda with allocated time per topic and key questions per topic. -- A practical process/flow for running the meeting to achieve the stated purpose. -- Internally reason from meeting goals, stakeholders, and constraints; return only the required final sections. - -FORMAT -Return exactly this structure: - - -[Clear and concise purpose statement] - - - -1. [Agenda Topic 1] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -2. [Agenda Topic 2] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -[Additional agenda topics] - - - -[Suggested process and flow for the meeting] - - -FAILURE -- Any required section (``, ``, ``) is missing or materially incomplete. -- Agenda items do not include both time allocation and key questions. -- Meeting flow/process is generic and not tied to the stated purpose. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md b/.factory/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md deleted file mode 100644 index bbf05acf..00000000 --- a/.factory/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: productize-meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- - - - -# Meeting Outcome Planning and Stakeholder Alignment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-outcome-planning-and-stakeholder-alignment` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md b/.factory/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md deleted file mode 100644 index 60997def..00000000 --- a/.factory/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-meeting-summaries-from-meeting-transcript-ideas-framework -description: >- - Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a - product workflow for presentation & communication related to meeting summaries from meeting - transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, - note-taking. ---- - - - -# Meeting summaries from meeting transcript (IDEAS framework) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-summaries-from-meeting-transcript-ideas-framework` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Meeting summaries from meeting transcript (IDEAS framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Meeting summaries from meeting transcript (IDEAS framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are tasked with summarizing a meeting using the IDEAS framework. This framework helps organize the key points of a meeting into five categories: Insights, Decisions, Engagements, Actions, and Summary. Here's the meeting transcript you need to analyze: - - -{{MEETING_TRANSCRIPT}} - - -Please carefully read and analyze the meeting transcript. Then, summarize the meeting using the IDEAS framework as follows: - -1. Insights: Identify and list the main insights or important realizations that emerged during the meeting. -2. Decisions: Note any decisions that were made during the meeting. -3. Engagements: List any tasks or responsibilities that were assigned to specific individuals or teams. -4. Actions: Highlight any immediate actions that need to be taken as a result of the meeting. -5. Summary: Provide a brief overall summary of the meeting's impact and significance. - -When writing your summary, please be concise and focused. Aim to capture the most important points rather than trying to include every detail. Use bullet points for each category to make the summary easy to read and understand. - -Present your summary using the following format, enclosed in XML tags: - -Remember to focus on the most significant and relevant information for each category. Your goal is to provide a clear, organized, and useful summary of the meeting using the IDEAS framework. - - -FORMAT -Return exactly this structure: - - - -โ€ข [List insights here] - - - -โ€ข [List decisions here] - - - -โ€ข [List engagements here] - - - -โ€ข [List actions here] - - - -[Write a brief overall summary here] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-message-framing-and-comms-plan-designer/SKILL.md b/.factory/skills/productize-message-framing-and-comms-plan-designer/SKILL.md deleted file mode 100644 index 8cc37534..00000000 --- a/.factory/skills/productize-message-framing-and-comms-plan-designer/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-message-framing-and-comms-plan-designer -description: >- - Message Framing & Comms Plan Designer. Use when the user needs a product workflow for - stakeholder management related to message framing & comms plan designer. Trigger terms: - communication, executive-communication, messaging, stakeholder-management. ---- - - - -# Message Framing & Comms Plan Designer - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `message-framing-and-comms-plan-designer` -- **Lifecycle**: Design -- **Category**: Marketing -- **Primary artifact**: Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Message Framing & Comms Plan Designer**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Message Framing & Comms Plan Designer. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use provided facts, audience, goal, and writing sample to design a message framing and communication plan. -- Provide 2-3 viable framing options, each with a one-line rationale tied to credibility, logic, and audience emotion. -- Produce two concise drafts in the user's natural tone: -- `ICs` draft with context, changes, actions, and timeline (`<=180` words). -- `Execs` draft with BLUF, risks/asks, and decision needed (`<=120` words). -- Include a strong subject/headline and two Slack snippets (announcement + reminder). -- Provide a mini comms plan with channel sequence, owner, timing, emphasis, and CTA. -- Include a `What to Omit` noise-reduction list and exactly 3 success signals. - -FORMAT -Return exactly this structure: - -Frames & Rationale -- [Frame 1]: [one-line rationale] -- [Frame 2]: [one-line rationale] -- [Frame 3 if used]: [one-line rationale] - -Draft for ICs -Subject/Headline: [text] -[ICs draft <=180 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Draft for Execs -Subject/Headline: [text] -[Execs draft <=120 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Mini Comms Plan -| Step | Channel | Owner | Timing | Emphasis | CTA | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -What to Omit -- [item] - -Success Signals -1. [signal] -2. [signal] -3. [signal] - -FAILURE -- Any required section is missing or materially incomplete. -- ICs draft exceeds 180 words or Execs draft exceeds 120 words. -- Missing subject/headline or missing either Slack snippet type (announcement/reminder). -- Comms plan table is missing required columns or sequence logic. -- Success Signals are not exactly three measurable indicators. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.factory/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md b/.factory/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md deleted file mode 100644 index 364641cd..00000000 --- a/.factory/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- - - - -# Metric drops diagnosis with rigorous stepwise decomposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- **Lifecycle**: Strategize -- **Category**: Analytics -- **Primary artifact**: Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/.factory/skills/productize-metrics-review/SKILL.md b/.factory/skills/productize-metrics-review/SKILL.md deleted file mode 100644 index ce1527cf..00000000 --- a/.factory/skills/productize-metrics-review/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-metrics-review -description: >- - Review and analyze product metrics with trend analysis and actionable insights. Use when - running a weekly, monthly, or quarterly metrics review, investigating a spike or drop, - comparing against targets, or turning raw numbers into a scorecard with recommended actions. ---- - - - -# Metrics Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metrics-review` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Metric scorecard, trend diagnosis, and recommended action plan - -Review product metrics, identify trends, and surface action-oriented insights. - -## Argument Hint - -`
` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/.opencode/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md b/.opencode/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md deleted file mode 100644 index 58de7bfa..00000000 --- a/.opencode/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: productize-feature-impact-models-from-kpis-and-assumptions -description: >- - Feature impact models from KPIs and assumptions. Use when the user needs a product workflow - for business analysis related to feature impact models from kpis and assumptions. Trigger - terms: pm, business-analysis, financial-modeling, kpi-impact. ---- - - - -# Feature impact models from KPIs and assumptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-impact-models-from-kpis-and-assumptions` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Feature impact models from KPIs and assumptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_INFO}} -- {{KPIS_TO_ESTIMATE}} - - -GOAL -Produce a high-quality deliverable for: Feature impact models from KPIs and assumptions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Build a procedural task list that covers: - - key assumptions, - - baseline metric calculations, - - per-KPI impact estimation, - - sensitivity analysis. -- Execute the tasks and show calculations step by step using explicit formulas/equations. -- For each KPI, provide: - - point estimate, - - assumptions and calculations used, - - brief explanation of feature-to-KPI impact mechanism. -- If information is missing, state what is missing, add a reasonable assumption, label it clearly, and proceed. -- Prioritize transparent math and reasoning over spreadsheet-like verbosity. -- Keep conclusions focused on executive decision-making (investment impact, major drivers, key risks). - - -FORMAT -Return exactly this structure: - - - -[List the procedural tasks used to build the model] - - - -[Step-by-step calculations, formulas, assumptions, and point estimates for each KPI] - - - -[Feature overview, KPI estimate table/list, key assumptions, sensitivity-analysis takeaways, and executive conclusions] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md b/.opencode/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md deleted file mode 100644 index ba3f5a3b..00000000 --- a/.opencode/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- - - - -# Feature results analysis from draft to final report - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-results-analysis-from-draft-to-final-report` -- **Lifecycle**: Launch & Learn -- **Category**: Analytics -- **Primary artifact**: Feature results readout with iterate, rollback, kill, or scale recommendation - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-features-reframing-and-projects-shape-up/SKILL.md b/.opencode/skills/productize-features-reframing-and-projects-shape-up/SKILL.md deleted file mode 100644 index 0049fb31..00000000 --- a/.opencode/skills/productize-features-reframing-and-projects-shape-up/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: productize-features-reframing-and-projects-shape-up -description: >- - Features reframing and projects Shape Up. Use when the user needs a product workflow for - technical related to features reframing and projects shape up. Trigger terms: - product-strategy, shaping, scope-management, stakeholder-management, technical. ---- - - - -# Features reframing and projects Shape Up - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `features-reframing-and-projects-shape-up` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Features reframing and projects Shape Up**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_OR_PROJECT}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Features reframing and projects Shape Up. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reframe `{{FEATURE_OR_PROJECT}}` using Shape Up principles and provided `{{CONTEXT}}`. -- Provide a shaped work definition that is concrete enough for delivery but avoids build-phase implementation detail. -- Include: -- Appetite assessment (`1-2 weeks` or `6 weeks`) with rationale. -- Problem framing (problem-first, not solution-first). -- Boundary definition (in-scope / out-of-scope). -- Solution sketch at fat-marker level. -- Risks/rabbit holes and circuit-breakers. -- Explicit no-gos. -- Executive constraint language to secure scope commitment and prevent mid-cycle scope creep. -- Keep output focused on shaping quality, delivery constraints, and stakeholder alignment. - -FORMAT -Return exactly this structure: - -Shape Up Reframe - -Appetite Assessment -- Recommended appetite: [1-2 weeks or 6 weeks] -- Why this appetite: [rationale] - -Problem Framing -- Core problem: [problem statement] -- Why this matters now: [impact/context] -- Success condition: [what success looks like] - -Boundary Definition -- In scope: - - [item] -- Out of scope: - - [item] - -Solution Sketching (Fat Marker Level) -- Key approach: [high-level approach] -- Main interaction/surface 1: [conceptual behavior] -- Main interaction/surface 2: [conceptual behavior] - -Risks and Rabbit Holes -- [risk/rabbit hole] -- Circuit-breaker: [constraint or stop-rule] - -No-gos -- [explicit exclusion] - -Executive Constraints -- Commitment language: [specific wording to secure scope agreement] -- Change-control rule: [how new requests are handled mid-cycle] -- Escalation path: [who decides if scope must change] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Output drifts into build-phase implementation details instead of shaping-level decisions. -- Boundaries/no-gos are vague or do not constrain scope. -- Executive constraint handling is missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-finance-modeling-kernel/SKILL.md b/.opencode/skills/productize-finance-modeling-kernel/SKILL.md deleted file mode 100644 index 538d3739..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/SKILL.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: productize-finance-modeling-kernel -description: >- - Shared Productize Finance calculation and validation kernel for exact formulas, input - normalization, assumption checks, units, warnings, and acceptance-tested finance math used - by valuation, DCF, cost-of-capital, capital-structure, VC deal, and market-context skills. ---- - - - -# Finance Modeling Kernel - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `finance-modeling-kernel` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings - -## Purpose - -Shared calculation and validation library used by all Productize Finance skills. -Use this skill when a finance workflow needs exact formulas, normalized inputs, -assumption checks, error handling, units, or validation before making a recommendation. - -## Kernel Modules - -- `finance-modeling-kernel/time_value.py`: PV, FV, annuities, perpetuities, spot-rate streams. -- `finance-modeling-kernel/dcf.py`: NPV, IRR, payback, free cash flow, terminal value, ROIC, growth. -- `finance-modeling-kernel/returns.py`: realized returns, expected return, variance, volatility, covariance, correlation. -- `finance-modeling-kernel/risk.py`: portfolio variance, covariance, correlation, beta, regression beta. -- `finance-modeling-kernel/capm.py`: CAPM, unlevered beta, relevered beta. -- `finance-modeling-kernel/wacc.py`: WACC with market-value weights. -- `finance-modeling-kernel/apv.py`: tax shields and APV. -- `finance-modeling-kernel/valuation.py`: DCF valuation, terminal value, EV-to-equity bridge, multiples, sensitivities. -- `finance-modeling-kernel/capital_structure.py`: EV, equity value, leverage, MM, tax shields, APV. -- `finance-modeling-kernel/bond_math.py`: bond price, yield to maturity, current yield, credit spread. -- `finance-modeling-kernel/vc_method.py`: burn, runway, VC target multiple, pre/post-money, shares. -- `finance-modeling-kernel/cap_table.py`: fully diluted shares, ownership, dilution, cap table sum checks. -- `finance-modeling-kernel/convertible_notes.py`: note conversion amount, discount price, cap price, shares. -- `finance-modeling-kernel/safes.py`: SAFE conversion price, SAFE shares, post-money SAFE ownership. -- `finance-modeling-kernel/preferred_stock.py`: liquidation preference and preferred payoff waterfalls. -- `finance-modeling-kernel/option_pools.py`: investor-friendly and founder-friendly option pool math. -- `finance-modeling-kernel/market_context.py`: market cap, weights, listing changes, CAGR. -- `finance-modeling-kernel/validation.py`: shared validation errors and warning helpers. -- `finance-modeling-kernel/tests/`: acceptance tests for the minimum formula examples. - -## Finance Output Format - -All Productize Finance agents must return: - -1. **Inputs** -2. **Assumptions** -3. **Formula used** -4. **Calculation** -5. **Result** -6. **Interpretation** -7. **Warnings** - -## Global Guardrails - -1. Never compare cash flows at different dates without compounding or discounting. -2. Use market values, not book values, for valuation and WACC weights whenever possible. -3. Match discount rates to cash-flow risk. -4. Do not use a company WACC for a project with materially different risk. -5. Do not mix financing cash flows into operating free cash flow. -6. Use NPV as the primary investment decision rule. -7. Treat IRR, payback, and multiples as supporting tools, not final truth. -8. For VC deals, always state whether share counts are basic or fully diluted. -9. For option pools, always state whether the pool is investor-friendly or founder-friendly. -10. For convertible notes and SAFEs, always read the conversion definition before calculating. -11. For preferred stock, model the payoff waterfall, not only the ownership percentage. - -## Workflow - -1. Identify the finance problem and the cash-flow timing, units, currency, and risk basis. -2. Choose the exact module and function; do not invent ad hoc formulas when a kernel function exists. -3. Validate formula preconditions, especially `r > g`, positive denominators, share-count basis, and market-value weights. -4. Calculate transparently enough that the user can audit the math. -5. Return the standard Finance output format and warnings. - -## Acceptance Tests - -Run: - -```sh -python3 skills/finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py -``` - -The test suite covers DCF NPV, growing perpetuity, CAPM, WACC, VC target multiple, -post-money/pre-money, convertible note discount conversion, investor-friendly option -pool, and non-participating preferred payoff. diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py deleted file mode 100644 index 754f2374..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py +++ /dev/null @@ -1,10 +0,0 @@ -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py deleted file mode 100644 index bbbe83d7..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py +++ /dev/null @@ -1,36 +0,0 @@ -from validation import FinanceValidationError, require_positive - - -def bond_price(coupon, face_value, yield_to_maturity, periods): - if yield_to_maturity == 0: - return coupon * periods + face_value - return coupon * (1 - (1 + yield_to_maturity) ** (-periods)) / yield_to_maturity + face_value / (1 + yield_to_maturity) ** periods - - -def yield_to_maturity(price, coupon, face_value, periods, tolerance=1e-7, max_iterations=200): - require_positive("price", price) - low = -0.999999 - high = 1.0 - while bond_price(coupon, face_value, high, periods) > price and high < 1000: - high *= 2 - if high >= 1000: - raise FinanceValidationError("Yield to maturity could not be bracketed.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_price = bond_price(coupon, face_value, mid, periods) - if abs(mid_price - price) <= tolerance: - return mid - if mid_price > price: - low = mid - else: - high = mid - return (low + high) / 2 - - -def current_yield(annual_coupon, bond_price_value): - require_positive("bond_price", bond_price_value) - return annual_coupon / bond_price_value - - -def credit_spread(risky_yield, risk_free_yield): - return risky_yield - risk_free_yield diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py deleted file mode 100644 index 73d96466..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py +++ /dev/null @@ -1,19 +0,0 @@ -from validation import require_positive - - -def fully_diluted_shares(common=0, preferred_as_converted=0, options_issued=0, option_pool_unissued=0, warrants=0, convertibles=0): - return common + preferred_as_converted + options_issued + option_pool_unissued + warrants + convertibles - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares - - -def dilution(old_ownership_percentage, new_ownership_percentage): - require_positive("old_ownership_percentage", old_ownership_percentage) - return 1 - new_ownership_percentage / old_ownership_percentage - - -def cap_table_sums_to_100(ownership_percentages, tolerance=1e-6): - return abs(sum(ownership_percentages) - 1) <= tolerance diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py deleted file mode 100644 index e8e7565e..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py +++ /dev/null @@ -1,51 +0,0 @@ -from validation import require_positive - - -def enterprise_value(equity_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return equity_value + debt + preferred_stock + minority_interest - cash - nonoperating_assets - - -def equity_value_from_ev(enterprise_value_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def debt_to_equity(debt, equity): - require_positive("equity", equity) - return debt / equity - - -def debt_to_value(debt, equity): - require_positive("debt plus equity", debt + equity) - return debt / (debt + equity) - - -def degree_of_financial_leverage(ebit, interest): - require_positive("ebit minus interest", ebit - interest) - return ebit / (ebit - interest) - - -def wacc(equity, debt, cost_of_equity, cost_of_debt, tax_rate): - total = equity + debt - require_positive("debt plus equity", total) - return equity / total * cost_of_equity + debt / total * (1 - tax_rate) * cost_of_debt - - -def mm_value_no_taxes(unlevered_value): - return unlevered_value - - -def mm_cost_of_equity_no_taxes(unlevered_cost_of_capital, cost_of_debt, debt, equity): - require_positive("equity", equity) - return unlevered_cost_of_capital + debt / equity * (unlevered_cost_of_capital - cost_of_debt) - - -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py deleted file mode 100644 index 19a58da7..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py +++ /dev/null @@ -1,21 +0,0 @@ -from validation import require_positive - - -def capm_cost_of_equity(risk_free_rate, beta, market_risk_premium): - return risk_free_rate + beta * market_risk_premium - - -def unlever_beta(beta_l, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_l / (1 + (1 - tax_rate) * debt / equity) - - -def relever_beta(beta_u, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_u * (1 + (1 - tax_rate) * debt / equity) - - -def asset_beta_with_debt_beta(beta_equity, beta_debt, debt, equity, tax_rate=0): - require_positive("total capital", debt + equity) - tax_adjusted_debt = debt * (1 - tax_rate) - return (beta_equity * equity + beta_debt * tax_adjusted_debt) / (equity + tax_adjusted_debt) diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py deleted file mode 100644 index 9d05470a..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py +++ /dev/null @@ -1,27 +0,0 @@ -from validation import require_positive - - -def convertible_note_conversion_amount(principal, interest_rate, time, compounding_method="simple"): - if compounding_method == "simple": - return principal * (1 + interest_rate * time) - if compounding_method == "compound": - return principal * (1 + interest_rate) ** time - raise ValueError("compounding_method must be simple or compound.") - - -def convertible_note_discount_price(series_a_price, discount_rate): - return (1 - discount_rate) * series_a_price - - -def convertible_note_cap_price(valuation_cap, cap_share_count): - require_positive("cap_share_count", cap_share_count) - return valuation_cap / cap_share_count - - -def convertible_note_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def convertible_note_shares(conversion_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return conversion_amount / conversion_price diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py deleted file mode 100644 index 204cb98b..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py +++ /dev/null @@ -1,73 +0,0 @@ -from validation import FinanceValidationError, require_positive, require_rate_greater_than_growth - - -def npv(initial_investment, cash_flows, discount_rate): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def npv_with_terminal_value(initial_investment, fcfs, discount_rate, terminal_value): - return npv(initial_investment, fcfs, discount_rate) + terminal_value / (1 + discount_rate) ** len(fcfs) - - -def irr(cash_flows, tolerance=1e-7, max_iterations=200): - def value(rate): - return sum(cash_flow / (1 + rate) ** period for period, cash_flow in enumerate(cash_flows)) - - low = -0.999999 - high = 1.0 - low_value = value(low) - high_value = value(high) - while low_value * high_value > 0 and high < 1000: - high *= 2 - high_value = value(high) - if low_value * high_value > 0: - raise FinanceValidationError("IRR could not be bracketed; cash flows may have no real IRR or multiple IRRs.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_value = value(mid) - if abs(mid_value) <= tolerance: - return mid - if low_value * mid_value < 0: - high = mid - high_value = mid_value - else: - low = mid - low_value = mid_value - return (low + high) / 2 - - -def payback_period(cash_flows): - cumulative = 0 - for period, cash_flow in enumerate(cash_flows): - cumulative += cash_flow - if cumulative >= 0: - return period - return None - - -def discounted_payback_period(cash_flows, discount_rate): - discounted = [cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows)] - return payback_period(discounted) - - -def free_cash_flow(ebit, tax_rate, depreciation, capex, delta_nwc): - return ebit * (1 - tax_rate) + depreciation - capex - delta_nwc - - -def terminal_value_gordon(fcf_next, discount_rate, growth_rate): - require_rate_greater_than_growth(discount_rate, growth_rate, "discount_rate") - return fcf_next / (discount_rate - growth_rate) - - -def roic(nopat, invested_capital): - require_positive("invested_capital", invested_capital) - return nopat / invested_capital - - -def reinvestment_rate(capex, depreciation, delta_nwc, nopat): - require_positive("nopat", nopat) - return (capex - depreciation + delta_nwc) / nopat - - -def sustainable_growth(roic_value, reinvestment_rate_value): - return roic_value * reinvestment_rate_value diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py deleted file mode 100644 index 7596a040..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py +++ /dev/null @@ -1,34 +0,0 @@ -from validation import require_positive - - -def market_cap(price, shares_outstanding): - return price * shares_outstanding - - -def market_weight(company_market_cap, total_market_cap): - require_positive("total_market_cap", total_market_cap) - return company_market_cap / total_market_cap - - -def index_weight(company_market_cap, index_total_market_cap): - require_positive("index_total_market_cap", index_total_market_cap) - return company_market_cap / index_total_market_cap - - -def global_lookthrough_weight(index_weight_value, index_share_of_country_market, country_share_of_world_market): - return index_weight_value * index_share_of_country_market * country_share_of_world_market - - -def change_in_listings(start_listings, end_listings): - return end_listings - start_listings - - -def percentage_change(start_value, end_value): - require_positive("start_value", start_value) - return end_value / start_value - 1 - - -def cagr(beginning_value, ending_value, years): - require_positive("beginning_value", beginning_value) - require_positive("years", years) - return (ending_value / beginning_value) ** (1 / years) - 1 diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py deleted file mode 100644 index e593de1a..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py +++ /dev/null @@ -1,22 +0,0 @@ -def investor_friendly_option_pool(existing_shares, investor_target_ownership, target_option_pool): - total_post_money_shares = existing_shares / (1 - investor_target_ownership - target_option_pool) - investor_shares = investor_target_ownership * total_post_money_shares - option_pool_shares = target_option_pool * total_post_money_shares - existing_holder_ownership = existing_shares / total_post_money_shares - return { - "total_post_money_shares": total_post_money_shares, - "investor_shares": investor_shares, - "option_pool_shares": option_pool_shares, - "existing_holder_ownership": existing_holder_ownership, - } - - -def founder_friendly_option_pool(existing_shares, investor_shares, target_option_pool): - total_post_pool_shares = (existing_shares + investor_shares) / (1 - target_option_pool) - option_pool_shares = target_option_pool * total_post_pool_shares - investor_ownership_final = investor_shares / total_post_pool_shares - return { - "total_post_pool_shares": total_post_pool_shares, - "option_pool_shares": option_pool_shares, - "investor_ownership_final": investor_ownership_final, - } diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py deleted file mode 100644 index 2906dad5..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py +++ /dev/null @@ -1,19 +0,0 @@ -def liquidation_preference(investment, liquidation_multiple=1, accrued_dividends=0): - return investment * liquidation_multiple + accrued_dividends - - -def nonparticipating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership): - return max(liquidation_preference_value, as_converted_ownership * exit_value) - - -def participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences): - if exit_value <= total_preferences: - return min(exit_value, liquidation_preference_value) - return liquidation_preference_value + as_converted_ownership * (exit_value - total_preferences) - - -def capped_participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences, cap_multiple, investment): - uncapped = participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences) - capped = min(uncapped, cap_multiple * investment) - converted = as_converted_ownership * exit_value - return max(capped, converted) diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py deleted file mode 100644 index 7e925a81..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py +++ /dev/null @@ -1,48 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def realized_return(price_start, price_end, dividend=0): - require_positive("price_start", price_start) - return (price_end - price_start + dividend) / price_start - - -def expected_return(returns, probabilities): - require_same_length("returns", returns, "probabilities", probabilities) - return sum(probability * return_value for return_value, probability in zip(returns, probabilities)) - - -def variance(returns, probabilities): - mean = expected_return(returns, probabilities) - return sum(probability * (return_value - mean) ** 2 for return_value, probability in zip(returns, probabilities)) - - -def standard_deviation(returns, probabilities): - return sqrt(variance(returns, probabilities)) - - -def historical_average_return(returns): - require_positive("number of returns", len(returns)) - return sum(returns) / len(returns) - - -def portfolio_expected_return(weights, expected_returns): - require_same_length("weights", weights, "expected_returns", expected_returns) - return sum(weight * expected_return_value for weight, expected_return_value in zip(weights, expected_returns)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py deleted file mode 100644 index bf065db7..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py +++ /dev/null @@ -1,41 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def portfolio_variance(weights, covariance_matrix): - rows = len(covariance_matrix) - require_same_length("weights", weights, "covariance_matrix rows", covariance_matrix) - for row in covariance_matrix: - require_same_length("weights", weights, "covariance_matrix row", row) - return sum(weights[i] * weights[j] * covariance_matrix[i][j] for i in range(rows) for j in range(rows)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) - - -def beta(asset_returns, market_returns): - market_variance = covariance(market_returns, market_returns) - require_positive("market variance", market_variance) - return covariance(asset_returns, market_returns) / market_variance - - -def estimate_beta_regression(asset_returns, market_returns, risk_free_rates): - require_same_length("asset_returns", asset_returns, "market_returns", market_returns) - require_same_length("asset_returns", asset_returns, "risk_free_rates", risk_free_rates) - excess_asset = [asset - risk_free for asset, risk_free in zip(asset_returns, risk_free_rates)] - excess_market = [market - risk_free for market, risk_free in zip(market_returns, risk_free_rates)] - return beta(excess_asset, excess_market) diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py deleted file mode 100644 index b8fcc474..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py +++ /dev/null @@ -1,15 +0,0 @@ -from validation import require_positive - - -def safe_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def safe_shares(investment_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return investment_amount / conversion_price - - -def post_money_safe_ownership(investment_amount, post_money_valuation_cap): - require_positive("post_money_valuation_cap", post_money_valuation_cap) - return investment_amount / post_money_valuation_cap diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py deleted file mode 100644 index 6d7850ba..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py +++ /dev/null @@ -1,42 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth, require_same_length - - -def future_value(cash_flow, rate, periods): - return cash_flow * (1 + rate) ** periods - - -def present_value(cash_flow, rate, periods): - return cash_flow / (1 + rate) ** periods - - -def present_value_stream(cash_flows, rate): - return sum(present_value(cash_flow, rate, period) for period, cash_flow in enumerate(cash_flows, start=1)) - - -def present_value_with_spot_rates(cash_flows, spot_rates): - require_same_length("cash_flows", cash_flows, "spot_rates", spot_rates) - return sum(present_value(cash_flow, spot_rate, period) for period, (cash_flow, spot_rate) in enumerate(zip(cash_flows, spot_rates), start=1)) - - -def annuity_pv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * (1 - (1 + rate) ** (-periods)) / rate - - -def annuity_fv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * ((1 + rate) ** periods - 1) / rate - - -def perpetuity_pv(payment, rate): - require_positive("rate", rate) - return payment / rate - - -def growing_perpetuity_pv(next_payment, rate, growth_rate): - require_rate_greater_than_growth(rate, growth_rate) - return next_payment / (rate - growth_rate) diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py deleted file mode 100644 index a94535ec..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py +++ /dev/null @@ -1,33 +0,0 @@ -class FinanceValidationError(ValueError): - """Raised when a finance formula cannot be applied safely.""" - - -def require_positive(name, value): - if value <= 0: - raise FinanceValidationError(f"{name} must be positive.") - return value - - -def require_nonnegative(name, value): - if value < 0: - raise FinanceValidationError(f"{name} must be nonnegative.") - return value - - -def require_rate_greater_than_growth(rate, growth_rate, rate_name="rate"): - if rate <= growth_rate: - raise FinanceValidationError(f"{rate_name} must be greater than growth rate.") - - -def require_same_length(name_a, values_a, name_b, values_b): - if len(values_a) != len(values_b): - raise FinanceValidationError(f"{name_a} and {name_b} must have the same length.") - - -def warn_if(condition, message, warnings=None): - if not condition: - return warnings if warnings is not None else [] - if warnings is None: - warnings = [] - warnings.append(message) - return warnings diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py deleted file mode 100644 index 5c97d94a..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py +++ /dev/null @@ -1,55 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth - - -def value_project_dcf(cash_flows, discount_rate, initial_investment): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def value_company_dcf(free_cash_flows, wacc, terminal_value): - return sum(fcf / (1 + wacc) ** period for period, fcf in enumerate(free_cash_flows, start=1)) + terminal_value / (1 + wacc) ** len(free_cash_flows) - - -def calculate_terminal_value_gordon(fcf_next, wacc, growth_rate): - require_rate_greater_than_growth(wacc, growth_rate, "wacc") - return fcf_next / (wacc - growth_rate) - - -def calculate_terminal_value_exit_multiple(metric, multiple): - return metric * multiple - - -def bridge_enterprise_to_equity_value(enterprise_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def calculate_price_per_share(equity_value, diluted_shares): - require_positive("diluted_shares", diluted_shares) - return equity_value / diluted_shares - - -def run_comparable_company_valuation(company_metric, comparable_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in comparable_multiples] - - -def run_precedent_transaction_valuation(company_metric, transaction_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in transaction_multiples] - - -def calculate_implied_multiple(value, metric): - require_positive("metric", metric) - return value / metric - - -def calculate_implied_value(metric, multiple): - return metric * multiple - - -def run_sensitivity_table(inputs, output_metric): - rows = [] - for case_name, case_inputs in inputs.items(): - rows.append({"case": case_name, "value": output_metric(**case_inputs)}) - return rows - - -def run_scenario_analysis(base_case, upside_case, downside_case): - return {"base": base_case, "upside": upside_case, "downside": downside_case} diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py deleted file mode 100644 index 77d56314..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py +++ /dev/null @@ -1,57 +0,0 @@ -from validation import require_positive - - -def burn_rate(monthly_expenses, monthly_cash_receipts=0): - return monthly_expenses - monthly_cash_receipts - - -def runway(cash_balance, monthly_net_burn): - require_positive("monthly_net_burn", monthly_net_burn) - return cash_balance / monthly_net_burn - - -def vc_target_multiple(required_return, holding_period, probability_success): - require_positive("probability_success", probability_success) - return (1 + required_return) ** holding_period / probability_success - - -def vc_present_value(successful_exit_value, probability_success, required_return, holding_period): - return successful_exit_value * probability_success / (1 + required_return) ** holding_period - - -def vc_total_valuation(successful_exit_value, retention, target_multiple): - require_positive("target_multiple", target_multiple) - return successful_exit_value * retention / target_multiple - - -def vc_partial_valuation(proposed_ownership, total_valuation): - return proposed_ownership * total_valuation - - -def vc_required_ownership(required_investment, total_valuation): - require_positive("total_valuation", total_valuation) - return required_investment / total_valuation - - -def post_money(investment, ownership): - require_positive("ownership", ownership) - return investment / ownership - - -def pre_money(post_money_value, investment): - return post_money_value - investment - - -def price_per_share(pre_money_value, fully_diluted_pre_money_shares): - require_positive("fully_diluted_pre_money_shares", fully_diluted_pre_money_shares) - return pre_money_value / fully_diluted_pre_money_shares - - -def new_shares(investment, price_per_share_value): - require_positive("price_per_share", price_per_share_value) - return investment / price_per_share_value - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares diff --git a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py b/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py deleted file mode 100644 index b147c830..00000000 --- a/.opencode/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py +++ /dev/null @@ -1,9 +0,0 @@ -from validation import require_positive - - -def wacc(equity_value, debt_value, cost_of_equity, cost_of_debt, tax_rate): - total_value = equity_value + debt_value - require_positive("debt plus equity", total_value) - equity_weight = equity_value / total_value - debt_weight = debt_value / total_value - return equity_weight * cost_of_equity + debt_weight * (1 - tax_rate) * cost_of_debt diff --git a/.opencode/skills/productize-financial-markets-context/SKILL.md b/.opencode/skills/productize-financial-markets-context/SKILL.md deleted file mode 100644 index f0ea115f..00000000 --- a/.opencode/skills/productize-financial-markets-context/SKILL.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -name: productize-financial-markets-context -description: >- - Productize Finance context skill for market capitalization, market weights, index - concentration, listed-firm trends, public-company comparables, sector shifts, and CAPM - market-portfolio assumptions. ---- - - - -# Financial Markets Context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `financial-markets-context` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings - -## Purpose - -Market context skill. Use it to interpret public-market facts, index concentration, -listed-firm trends, market capitalization, comparable-company assumptions, sector -shifts, and market portfolio assumptions in CAPM. - -## Core Formulas - -- `Market Cap_i = Share Price_i * Shares Outstanding_i` -- `Weight_i = Market Cap_i / Total Market Cap` -- `Index Weight_i = Market Cap_i / sum(Market Cap of All Index Constituents)` -- `Global Weight_i = index weight * index share of country market * country share of world market` -- `Change in Listings = Listings_End - Listings_Start` -- `% Change = (End / Start - 1) * 100` -- `CAGR = (Ending Value / Beginning Value)^(1 / Years) - 1` - -## Interpretation Rules - -- Fewer listed firms does not necessarily mean a smaller equity market. -- Market capitalization can rise even if listings fall. -- This can happen because public firms become larger, smaller firms delist, and mergers concentrate value. -- Index concentration matters because the CAPM market portfolio is value-weighted. -- Public comparables may be biased if the target is much smaller, less mature, less profitable, or in a different sector. -- Sector composition changes over time, so historical index returns may reflect sector shifts, not only broad economic growth. - -## Required Validation - -- Warn if equal weighting is confused with value weighting. -- Warn if index concentration is ignored. -- Warn if public comparables are used for a startup without maturity adjustments. -- Warn if global market assumptions use only one domestic index. -- Warn if stale market weights are used. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Separate market fact, valuation implication, and comparability risk. diff --git a/.opencode/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md b/.opencode/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md deleted file mode 100644 index 55ad6c4c..00000000 --- a/.opencode/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md +++ /dev/null @@ -1,422 +0,0 @@ ---- -name: productize-fragmented-user-research-synthesis-into-coherent-insights -description: >- - Fragmented user research synthesis into coherent insights. Use when the user needs a product - workflow for user research related to fragmented user research synthesis into coherent - insights. Trigger terms: user-research, synthesis, insights. ---- - - - -# Fragmented user research synthesis into coherent insights - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `fragmented-user-research-synthesis-into-coherent-insights` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Fragmented user research synthesis into coherent insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{RESEARCH_INPUTS}} -- {{PRODUCT_CONTEXT}} -- {{DESIGN_QUESTIONS}} -- {{CURRENT_ASSUMPTIONS}} -- {{BUSINESS_GOALS}} - - -GOAL -Produce a high-quality deliverable for: Fragmented user research synthesis into coherent insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Synthesize fragmented research inputs into coherent, evidence-based insights that inform design and product decisions. -- Use the provided inputs: -- `{{RESEARCH_INPUTS}}` -- `{{PRODUCT_CONTEXT}}` -- `{{DESIGN_QUESTIONS}}` -- `{{CURRENT_ASSUMPTIONS}}` -- `{{BUSINESS_GOALS}}` -- Perform synthesis rigorously: -- Inventory and assess source quality/coverage. -- Extract coded observations (quotes, behaviors, themes, segment/context metadata). -- Identify cross-source patterns and contradictions. -- Assign confidence levels with explicit rationale. -- Map insights to JTBD and user-needs hierarchy. -- Link insights directly to design questions and actionable recommendations. -- Identify research gaps, unresolved assumptions, and prioritized follow-up research. -- Keep evidence traceable, avoid over-generalization, and state assumptions/uncertainties explicitly. - -FORMAT -Return exactly this structure: - - - -**Data Sources Summary:** -- User interviews: [X participants] covering [topics, user segments, dates] -- Support tickets: [Y tickets] from [date range] about [primary themes] -- NPS feedback: [Z responses] with [average score] discussing [key topics] -- Usage analytics: [data range, key metrics, user actions analyzed] -- Feature requests: [count] requests across [platforms/sources] -- Usability tests: [sessions count] testing [specific flows or features] -- Survey data: [respondents count] on [topics covered] -- Anecdotal feedback: [source count] from [stakeholders, channels] -- Session recordings: [count] sessions showing [behaviors] -- Other sources: [specify any additional data] - -**Data Quality Assessment:** -- Time range: [how recent is this data?] -- User segment coverage: [which personas/segments are represented?] -- Sample size adequacy: [sufficient for confidence in findings?] -- Potential bias: [what perspectives might be over/under-represented?] -- Data completeness: [what's missing or sparse?] - - - - -**Insight Statement:** -[One clear, specific sentence stating what you learned about users] - -**Evidence:** -- User interviews: "[verbatim quote]" (Participant X, [segment]) -- Support tickets: [Y tickets] report "[specific issue]" with keywords: [terms] -- NPS feedback: "[example comment]" (common theme in Z% of detractor responses) -- Analytics data: [X% of users] exhibit [specific behavior], [frequency/context] -- Additional evidence: [any other supporting data points] - -**Confidence Level:** High / Medium / Low -**Rationale for Confidence:** [Why you assigned this confidence level] - -**User Segments Affected:** -- [Segment 1]: [how this manifests for them] -- [Segment 2]: [how this manifests for them] - -**Jobs-to-be-Done Connection:** -[Which job is this insight related to? How does it help or hinder job completion?] - -**Design Implications:** -- Consider: [specific design approach this suggests] -- Avoid: [what this insight argues against] -- Prioritize: [which aspect of the experience to focus on] -- Measure: [how to validate design addressed this insight] - -**Related Patterns:** -[Which other insights connect to this? How do they reinforce or complicate each other?] - -**Business Impact:** -[How does addressing this insight connect to business goals or metrics?] - - - -[Repeat the full structure for 5-10 key insights, maintaining consistent depth and evidence rigor] - - - -[Continue for all major insights...] - - - - -**Conflict 1:** -- Signal A: [what one source or segment indicates] -- Signal B: [what contradicts this] -- Possible explanations: - * [Explanation 1: e.g., different user segments with different needs] - * [Explanation 2: e.g., stated preference vs. actual behavior] - * [Explanation 3: e.g., context-dependent variation] -- Recommended resolution: [What research or analysis would clarify this?] -- Design strategy given conflict: [How to proceed despite uncertainty?] - -**Conflict 2:** -[Repeat structure for each major contradiction in the data] - -**Synthesis:** -[What do these conflicts reveal about user diversity, product complexity, or research gaps?] - - - -**Question 1:** [Restate the first design question] -- **Answer based on research:** [What the data tells you] -- **Supporting insights:** [Which insights from above inform this answer] -- **Confidence level:** High / Medium / Low -- **Caveats and limitations:** [What qualifies or nuances this answer] -- **What we still don't know:** [Gaps specific to this question] -- **Recommended action:** [What to design/test/research next] - -**Question 2:** [Restate the second design question] -[Repeat structure for each design question provided] - -**New Questions Surfaced:** -[Design questions that emerged from the research but weren't originally asked] - - - - -**Must-Have Needs (Strong Evidence, High Impact):** -1. [Need 1]: [description] - - Evidence: [cross-source validation] - - If unmet: [severe user/business consequence] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat structure for 3-5 critical needs] - - - -**Should-Have Needs (Moderate Evidence, Meaningful Impact):** -1. [Need 1]: [description] - - Evidence: [validation from 1-2 strong sources] - - If unmet: [moderate user friction or business impact] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat for 5-8 important needs] - - - -**Nice-to-Have Needs (Weak Signal, Low/Uncertain Impact):** -1. [Need 1]: [description] - - Evidence: [limited mentions or single source] - - Potential value: [why this might matter despite weak signal] - - Validation needed: [how to test if this is actually important] - -2. [Need 2]: [description] - [Repeat for 3-5 nice-to-have needs] - - - -**Segment-Specific Needs:** -- [Segment A]: [unique needs not shared by other segments] -- [Segment B]: [unique needs not shared by other segments] -- [Universal needs]: [needs expressed across all segments] - - - - -**Current Workflows and Workarounds:** -[Describe how users actually accomplish tasks today, including inefficient or creative workarounds that reveal unmet needs] - -**Decision-Making Patterns:** -[How users make choices within the product, what information they seek, what causes hesitation or confidence] - -**Pain Point Triggers:** -[Specific circumstances, contexts, or actions that consistently lead to user frustration] - -**Success Patterns:** -[When and how users successfully achieve their goals, what enables their success] - -**Usage Context and Frequency:** -[When, where, why, and how often users engage with the product or specific features] - -**Adoption and Learning Patterns:** -[How users onboard themselves, what helps or hinders learning, common confusion points] - -**Abandonment and Recovery Patterns:** -[What causes users to give up, what brings them back, how they recover from errors] - -**Cross-Tool Workflows:** -[How users combine your product with other tools, what gaps force tool-switching] - - - -**Primary Functional Jobs:** -1. [Job]: When [situation], I want to [motivation], so I can [expected outcome] - - Evidence: [how research revealed this job] - - Current obstacles: [what prevents job completion] - - Success criteria: [how users define successful job completion] - -2. [Job]: [Repeat structure for 3-5 primary jobs] - -**Emotional Jobs:** -- [Feel]: [emotion users want to feel, e.g., "feel confident in my decisions"] -- [Avoid]: [emotion users want to avoid, e.g., "avoid feeling overwhelmed"] -- Evidence: [quotes, observations, sentiment indicators] - -**Social Jobs:** -- [Perception]: [how users want to be seen, e.g., "be perceived as data-driven"] -- [Context]: [social situations where product use matters] -- Evidence: [research indicators of social motivations] - -**Related Jobs in the Consumption Chain:** -- Before main job: [how users discover, evaluate, and choose the product] -- After main job: [how users share, report, or build on outcomes] -- Maintenance jobs: [ongoing tasks to keep getting value] - - - - -**Critical Unknowns (Blocking Design Decisions):** -1. [Question]: [why this matters for design] -2. [Question]: [why this matters for design] -3. [Question]: [why this matters for design] - -**Important Unknowns (Would Significantly Inform Design):** -1. [Question]: [how this would help] -2. [Question]: [how this would help] - -**Curiosities (Interesting But Not Urgent):** -1. [Question]: [potential value] -2. [Question]: [potential value] - - - -**Research Activity 1:** -- **Method:** [interviews / usability testing / survey / analytics deep-dive / diary study / etc.] -- **Target participants:** [which user segments, how many, recruitment criteria] -- **Key questions to answer:** [specific questions this research would resolve] -- **Expected outcomes:** [what you'll learn and how it informs design] -- **Effort estimate:** [time and resources required] -- **Priority:** High / Medium / Low - [rationale] - -**Research Activity 2:** -[Repeat structure for 3-5 recommended research activities, prioritized by impact and urgency] - - - -**Design Assumptions:** -1. [Assumption about user behavior or preferences]: Currently [validated / unvalidated / contradicted] by research -2. [Assumption about priorities or needs]: Currently [status] -3. [Assumption about technical or business constraints]: Currently [status] - -**Team Assumptions:** -[Assumptions stakeholders or team members hold that aren't supported by dataโ€”list with gentle evidence-based reframing] - -**Testing Strategy:** -[How to quickly validate or invalidate the most critical assumptions through lightweight tests] - - - - -**Priority 1 Recommendations (Supported by High-Confidence Insights):** -1. [Specific design action]: [rationale tied to insight X, Y, Z] - - Expected impact: [user and business outcomes] - - Success metrics: [how to measure if this worked] - -2. [Specific design action]: [rationale tied to insights] - [Repeat for 3-5 top-priority recommendations] - -**Priority 2 Recommendations (Supported by Medium-Confidence Insights):** -1. [Specific design action]: [rationale] - [Repeat for 5-7 secondary recommendations] - -**Quick Wins (Low Effort, Clear User Value):** -1. [Specific design action]: [why this is easy and valuable] - [Repeat for 3-5 quick wins] - -**Strategic Bets (Lower Confidence, High Potential):** -1. [Specific design action]: [why worth exploring despite uncertainty] - - Validation approach: [how to test before full commitment] - [Repeat for 2-3 strategic bets] - -**Do Not Pursue:** -[Features, changes, or directions that research argues against, with rationale] - - - -**Executive Summary** - -**What We Learned:** -[2-3 sentences capturing the most important insights from the research] - -**User Needs Priority:** -Users critically need [top need], strongly want [second need], and would appreciate [third need]. The evidence is strongest for [insight area] and weakest for [insight area requiring validation]. - -**Key Behavioral Patterns:** -[1-2 sentences on how users actually behave vs. what we might have assumed] - -**Design Implications:** -The research strongly supports [recommended direction 1] and [recommended direction 2], while arguing against [current assumption or planned direction]. We should prioritize [specific user segment or job-to-be-done] because [evidence-based rationale]. - -**Critical Unknowns:** -We still need to understand [key gap 1] and [key gap 2] through [recommended research method]. - -**Recommended Next Steps:** -1. [Immediate action based on high-confidence insights] -2. [Design exploration for medium-confidence opportunities] -3. [Targeted research to fill critical gaps] - -**Business Impact:** -Addressing these insights is expected to improve [business metric] by [directional estimate] because [user behavior change expected]. - -[Total: 250-350 words] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Insights are not supported by cross-source evidence or confidence rationale. -- Contradictions are ignored or not addressed with a resolution approach. -- Recommendations are not prioritized or not linked to synthesized insights/business goals. -- Research gaps and assumption validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md b/.opencode/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md deleted file mode 100644 index fc5dbcfc..00000000 --- a/.opencode/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -name: productize-framework-application-to-product-challenges-from-user-input -description: >- - Framework application to product challenges from user input. Use when the user needs a - product workflow for product strategy related to framework application to product challenges - from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching. ---- - - - -# Framework application to product challenges from user input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `framework-application-to-product-challenges-from-user-input` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Framework application to product challenges from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRAMEWORK}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Framework application to product challenges from user input. -Success metric: -- Asks targeted questions when key context is missing. -- Applies the provided framework precisely to the userโ€™s situation. -- Produces actionable advice and a clear recommendation when sufficient context exists. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{FRAMEWORK}}` and `{{USER_INPUT}}`; if key context is missing, ask targeted questions first. -- Do not summarize the framework back to the user. -- When asking for more information, use `` tags only. -- When providing guidance, use `` tags only. -- When providing a final recommendation, use `` tags only. -- Keep advice specific and grounded in the userโ€™s context; avoid generic PM guidance. - -FORMAT -Return exactly this structure: - - -[Targeted questions needed to apply the framework] - - - -[Framework-applied guidance once sufficient context exists] - - - -[Final recommendation when enough context exists] - - -FAILURE -- Required tags are missing or malformed. -- Output includes framework summary instead of application. -- Advice is generic or not tied to the user input. -- Recommendation is provided without sufficient context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-frontend-design/SKILL.md b/.opencode/skills/productize-frontend-design/SKILL.md deleted file mode 100644 index b21a1c23..00000000 --- a/.opencode/skills/productize-frontend-design/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-frontend-design -description: >- - Design implementation-ready frontend solutions with UX intent, component structure, - responsive behavior, accessibility, and handoff criteria. ---- - - - -# Frontend Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `frontend-design` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to design frontend behavior and UI structure before or alongside implementation. - -## The Process - -### Step 1: Define UX objective - -Capture: -- user goal -- primary user flow -- success state and failure states - -### Step 2: Specify UI architecture - -Define: -- screen/layout structure -- component hierarchy -- state model (loading, empty, error, success) - -### Step 3: Specify design system decisions - -Set: -- typography and spacing rules -- color/contrast constraints -- interaction patterns - -### Step 4: Specify responsive and accessibility requirements - -Include: -- breakpoints and behavior changes -- keyboard navigation expectations -- ARIA/semantic requirements -- contrast and focus visibility requirements - -### Step 5: Define implementation handoff - -Provide: -- component list and props/state contract -- acceptance criteria -- verification checklist - -## Output Format - -```markdown -# [Feature Name] Frontend Design Spec - -## UX Objective -- User goal: -- Primary flow: -- Success/failure states: - -## UI Architecture -- Layout: -- Component hierarchy: -- State model: - -## Responsive Behavior -- Desktop: -- Tablet: -- Mobile: - -## Accessibility Requirements -- Keyboard: -- Semantics/ARIA: -- Contrast/focus: - -## Handoff -- Components to implement: -- Acceptance criteria: -- Verification checklist: -``` - -## Quality Bar - -- Design decisions must map to user goals -- Accessibility section is mandatory -- Handoff must be implementable without extra interpretation - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/.opencode/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md b/.opencode/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md deleted file mode 100644 index 62097374..00000000 --- a/.opencode/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: productize-future-product-opportunities-from-market-inflection-points -description: >- - Future product opportunities from market inflection points. Use when the user needs a - product workflow for product strategy related to future product opportunities from market - inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, - trends, product-vision. ---- - - - -# Future product opportunities from market inflection points - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `future-product-opportunities-from-market-inflection-points` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Future product opportunities from market inflection points**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_YEAR}} -- {{RESEARCH_TIMEFRAME}} - - -GOAL -Produce a high-quality deliverable for: Future product opportunities from market inflection points. -Success metric: -- Identifies concrete regulatory, technological, and belief inflection points within the stated timeframe. -- Connects converging trends to 3โ€“5 plausible future opportunities. -- Provides actionable challenges and timelines for each opportunity. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_YEAR}}` and `{{RESEARCH_TIMEFRAME}}`; if context is missing, state assumptions explicitly. -- List 3โ€“5 items per inflection category (regulatory, technological, belief). -- Provide 3โ€“5 converging trend sets that explicitly combine at least two categories. -- Provide 3โ€“5 future opportunities with concept, enabling trends, challenges, and timeline. -- Keep opportunities plausible within the specified research timeframe. - -FORMAT -Return exactly this structure: - - -1. Inflection Points: - a. Regulatory: - - [List 3โ€“5 significant regulatory changes] - b. Technological: - - [List 3โ€“5 important technological advancements] - c. Belief: - - [List 3โ€“5 notable shifts in societal attitudes or behaviors] - -2. Converging Trends: - - [Describe 3โ€“5 sets of converging trends, explaining how they intersect] - -3. Future Opportunities: - [For each opportunity (aim for 3โ€“5), include:] - a. Concept: [Brief description] - b. Enabling Trends: [List the key inflection points or converging trends] - c. Challenges: [Potential barriers or difficulties] - d. Timeline: [Estimated timeframe for realization] - -4. Conclusion: - [Summarize the most promising areas for innovation based on your analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any inflection category has fewer than 3 or more than 5 items. -- Converging trends do not combine multiple categories. -- Opportunities are missing required fields or outside the specified timeframe. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-group-decision-making-quality-review/SKILL.md b/.opencode/skills/productize-group-decision-making-quality-review/SKILL.md deleted file mode 100644 index cb5bacdc..00000000 --- a/.opencode/skills/productize-group-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: productize-group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, or - operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group - decides. ---- - - - -# Group Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `group-decision-making-quality-review` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/.opencode/skills/productize-grow/SKILL.md b/.opencode/skills/productize-grow/SKILL.md deleted file mode 100644 index c1b5d4fb..00000000 --- a/.opencode/skills/productize-grow/SKILL.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: productize-grow -description: >- - Productize grow playbook for stable products with activation evidence. Use when the product - has a working core and the team needs growth diagnosis, growth loops, GTM choices, - onboarding, retention, pricing, lifecycle triggers, and experiment cadence. ---- - - - -# Productize Grow - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `grow` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition - -Use this playbook when the core product is stable enough to grow. Grow is not the -place to invent the product; use `$0-1` for new bets and `$operate` for continuous -production health. - -## Cadence - -- Trigger: stable activation, repeat usage, clear ICP, or a growth bottleneck. -- Rhythm: weekly experiment planning and readout, with metric reviews before changing - channels, onboarding, pricing, or lifecycle triggers. -- Closure: target hit, target abandoned, strategy pivot, or evidence that the product - needs a new `$0-1` loop. - -## Route Internally - -- Product-market fit and bottlenecks: `$product-market-fit-cycle`, `$aarrr-growth-diagnostics`, `$metrics-review` -- Loops and experiments: `$growth-loops`, `$plg-growth-playbook`, `$growth-project-generation-with-pioneer-migrator-settler`, `$robust-experiment-design-from-goals-and-systems` -- GTM and lifecycle: `$gtm-motions`, `$gtm-strategy`, `$onboarding-flow-optimization-from-product-data-to-user-success` -- Retention and monetization: `$churn-reduction-from-customer-data-and-exit-survey-analysis`, `$pricing-strategy`, `$monetization-strategy` -- Gates: `$product-review`, `$qa`, `$comms-review`, `$docs`, `$release` - -## Required Output - -Return: - -1. **Growth State**: ICP, activation evidence, retention signal, bottleneck, and metric caveats. -2. **Growth Thesis**: target, growth loop, channel or lifecycle trigger, and why it fits the current evidence. -3. **Experiment Cadence**: tests, owners, sample size or evidence threshold, and stop/pivot rules. -4. **Gate Calls**: product, QA, docs, release, or comms gates needed before launch. -5. **Closure Condition**: target hit, pivot, pause, or new `$0-1` bet. diff --git a/.opencode/skills/productize-growth-loops/SKILL.md b/.opencode/skills/productize-growth-loops/SKILL.md deleted file mode 100644 index 4f439fbc..00000000 --- a/.opencode/skills/productize-growth-loops/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: productize-growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- - - - -# Growth Loops - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-loops` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.opencode/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md b/.opencode/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md deleted file mode 100644 index 4c847103..00000000 --- a/.opencode/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-growth-project-generation-with-pioneer-migrator-settler -description: >- - Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a - product workflow for product strategy related to growth project generation with - pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, - portfolio. ---- - - - -# Growth project generation with Pioneer-Migrator-Settler framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-project-generation-with-pioneer-migrator-settler` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Growth project generation with Pioneer-Migrator-Settler framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY}} - - -GOAL -Produce a high-quality deliverable for: Growth project generation with Pioneer-Migrator-Settler framework. -Success metric: -- Produces 12 distinct growth projects categorized into Pioneer/Migrator/Settler. -- Ensures balanced portfolio logic and a brief plan to drive growth. -- Keeps ideas concrete, differentiated, and aligned to the company context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY}}`; if details are missing, state assumptions explicitly. -- Generate exactly 12 distinct growth projects: - - 3 creative, - - 3 weird, - - 3 compelling, - - 3 novel and unexpected. -- Each idea must be tagged as one of: Pioneer, Migrator, Settler. -- Keep ideas concrete and specific to the companyโ€™s context. -- Provide a brief analysis of portfolio balance and strategic impact. -- Provide a short growth plan for how to build new market space and profitable growth. - -FORMAT -Return exactly this structure: - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - - -[Brief analysis of mix and impact, with portfolio balance insights] - - - -[Brief plan for creating new market space and profitable growth] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer or more than 12 ideas are provided. -- Any idea is missing a Pioneer/Migrator/Settler category. -- Ideas are generic or not grounded in the company context. -- Analysis or growth plan is missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md b/.opencode/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md deleted file mode 100644 index 99d9f24c..00000000 --- a/.opencode/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: productize-growth-strategy-synthesis-from-user-inputs -description: >- - Growth strategy synthesis from user inputs. Use when the user needs a product workflow for - product strategy related to growth strategy synthesis from user inputs. Trigger terms: - growth, strategy, experimentation, metrics, distribution. ---- - - - -# Growth strategy synthesis from user inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-strategy-synthesis-from-user-inputs` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth strategy brief with bets, loops, experiments, and metrics - -Use this skill to run the Productize prompt contract for **Growth strategy synthesis from user inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUTS}} - - -GOAL -Produce a high-quality deliverable for: Growth strategy synthesis from user inputs. -Success metric: -- Produces a complete growth strategy across model, constraints, horizon, method, principle, and catalyst. -- Grounds all recommendations in the provided user inputs. -- Outputs actionable, testable recommendations and a concise summary. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUTS}}`; if critical data is missing, state assumptions explicitly. -- Address each required section: model, constraint, horizon, method, principle, catalyst, summary. -- Keep recommendations actionable and testable; avoid generic advice. -- If quantitative data is present, reference it; if not, use qualitative reasoning and label assumptions. - -FORMAT -Return exactly this structure: - - - -[Provide a detailed description of the growth model] - - - -[Identify and explain the main growth constraints] - - - -[Analyze the growth horizon and potential limitations] - - - -[Propose specific methods to address constraints and extend the growth horizon] - - - -[Develop a guiding principle for aligning the organization] - - - -[Identify and explain any growth catalysts] - - - -[Provide a brief summary of the overall growth strategy] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Recommendations are not tied to the provided inputs. -- Growth method lacks actionable steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-gtm-motions/SKILL.md b/.opencode/skills/productize-gtm-motions/SKILL.md deleted file mode 100644 index a9650ffb..00000000 --- a/.opencode/skills/productize-gtm-motions/SKILL.md +++ /dev/null @@ -1,236 +0,0 @@ ---- -name: productize-gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, - partner, ABM, or hybrid go-to-market motions. ---- - - - -# GTM Motions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-motions` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.opencode/skills/productize-gtm-strategy/SKILL.md b/.opencode/skills/productize-gtm-strategy/SKILL.md deleted file mode 100644 index 22360c0b..00000000 --- a/.opencode/skills/productize-gtm-strategy/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: productize-gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- - - - -# GTM Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.opencode/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md b/.opencode/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md deleted file mode 100644 index 5d62c3c7..00000000 --- a/.opencode/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- - - - -# Ideal Customer Profile (ICP) representative for X product - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideal-customer-profile-icp-representative-for-x-product` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/.opencode/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md b/.opencode/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md deleted file mode 100644 index 3be9171c..00000000 --- a/.opencode/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md +++ /dev/null @@ -1,171 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make ICP outputs sharper on demographics, behaviors, JTBD, PMF evidence, and best-customer patterns. - -## Routing Signals - -- ideal customer profile -- icp -- pmf survey -- best customers - -## pm-go-to-market/skills/ideal-customer-profile/SKILL.md - -## Overview -Identify your Ideal Customer Profile (ICP) from research and survey data. This skill synthesizes customer research to define the customer most likely to find value, retain, and expand with your product. - -## When to Use -- Defining ICP from product-market fit survey data -- Targeting high-value customer segments -- Analyzing customer success and expansion patterns -- Prioritizing sales and marketing efforts -- Evaluating new customer opportunities for fit -- Refining target market definition - -## ICP Framework Components - -### Demographics -Who are they from a firmographic and personal perspective? -- Company size (employees, revenue) -- Industry or vertical -- Geographic location -- Job title and department -- Years of experience in role -- Education and background -- Organizational structure and reporting - -### Behaviors -How do they work and make decisions? -- How they discover and evaluate solutions -- Buying process and decision-making timeline -- Technical literacy and product adoption speed -- Collaboration style (solo decision vs committee) -- Change management and adoption style -- Tool switching frequency -- Community involvement and peer influence - -### Jobs to Be Done (JTBD) -What are they trying to accomplish? -- Primary job/goal they're trying to achieve -- Secondary jobs that support the primary job -- Emotional jobs (how they want to feel) -- Social jobs (status and perception) -- Jobs they avoid or want to eliminate -- Frequency and importance of each job -- Success metrics for completing job - -### Needs and Pain Points -What problems does your product solve? -- Specific pain points they experience -- Current workarounds and limitations -- Impact on productivity or outcomes -- Cost or time burden of the problem -- Emotional frustration levels -- Barriers to solving the problem -- Available budget to solve -- Competing priorities - -## How It Works - -### Step 1: Gather Customer Data -Collect research about actual and potential customers: -- Product-market fit survey responses -- Customer interview transcripts -- Trial or freemium user behavior data -- Customer feedback and support tickets -- Churn analysis and customer lifecycle data -- Win/loss analysis from sales -- Competitor customer analysis - -### Step 2: Segment by Value -Identify customer cohorts and their value: -- Highest LTV (lifetime value) customers -- Fastest time-to-value customers -- Lowest churn rate customers -- Highest expansion/upsell customers -- Most enthusiastic/engaged customers -- Best reference/case study potential -- Most aligned with product vision - -### Step 3: Profile Demographics -Extract firmographic patterns: -- Common company sizes (employee count, revenue) -- Industry verticals and sub-verticals -- Geographic concentrations -- Typical department and reporting structure -- Budget holders and budget available -- Company stage (startup, growth, enterprise) -- Company culture indicators - -### Step 4: Identify Behaviors -Map decision-making and adoption patterns: -- How they discovered your product (channel) -- Evaluation process and timeline -- Key stakeholders in decision -- Obstacles during sales process -- Product adoption speed and breadth -- Team involvement in onboarding -- Frequency of feature usage -- Support and service needs - -### Step 5: Define JTBD -Articulate what they're trying to accomplish: -- Primary job/goal (functional job) -- Emotional dimensions (how they want to feel) -- Social dimensions (team and stakeholder impact) -- Success metrics (how they measure success) -- Context and constraints (when, where, with whom) -- Competing jobs and priorities -- Importance ranking of various jobs - -### Step 6: Document Pain Points and Needs -Synthesize specific problem areas: -- Before state (current situation and frustrations) -- Desired after state (ideal future state) -- Gap size and impact quantification -- Emotional dimensions of the problem -- Resource constraints preventing solutions -- Skepticism or hesitations -- Success criteria for solution - -## Input Format -Use $ARGUMENTS to pass: -- Research data (surveys, interviews, transcripts) -- Customer success/metrics data -- Product usage analytics -- Sales activity and win/loss data -- Existing customer database -- Competitive intelligence - -## Output -A comprehensive ICP definition including: -- Firmographic profile (company size, industry, location) -- Behavioral profile (buying patterns, adoption style) -- Complete JTBD mapping (functional, emotional, social jobs) -- Top 5-7 pain points and specific needs -- Quantified impact metrics (cost of problem, value of solution) -- Decision-making process and key stakeholders -- Typical customer journey and timeline -- Go-to-market implications and messaging -- Disqualification criteria (who is NOT a good fit) -- High-value segment within ICP (ideal-of-the-ideal) - -## Framework -Based on Jobs to Be Done theory by Clayton Christensen and customer profiling methodology. Combines behavioral data with motivational insights to define actionable customer profiles. - -## Tips -- Use quantitative and qualitative data together -- Interview 10+ high-value customers for pattern identification -- Look for non-obvious demographic patterns (outliers can be high-value) -- Define both ideal ICP and acceptable secondary segments -- Revisit ICP quarterly as you gather more customer data -- Use ICP to evaluate all new sales opportunities -- Share ICP across entire organization (marketing, sales, product) -- Remember: ICP should drive focus, not exclude all others - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/.opencode/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md b/.opencode/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md deleted file mode 100644 index 34c8b07f..00000000 --- a/.opencode/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem -description: >- - Ideas for affordances and signifiers based on a design problem. Use when the user needs a - product workflow for design & prototyping related to ideas for affordances and signifiers - based on a design problem. Trigger terms: ux, interaction-design, affordances, usability. ---- - - - -# Ideas for affordances and signifiers based on a design problem - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideas-for-affordances-and-signifiers-based-on-a-design-problem` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Ideas for affordances and signifiers based on a design problem**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_CHALLENGE}} - - -GOAL -Produce a high-quality deliverable for: Ideas for affordances and signifiers based on a design problem. -Success metric: -- Identifies key user interactions in the design challenge before proposing ideas. -- Produces at least 5 concrete ideas each for affordances, perceived affordances, and signifiers. -- Each idea includes a brief explanation tied to the challenge and UX impact. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DESIGN_CHALLENGE}}`; if context is incomplete, state assumptions explicitly. -- Start with a brief interaction analysis identifying main user functions/tasks. -- Generate at least 5 ideas in each category: affordances, perceived affordances, signifiers. -- For every idea, include a short explanation linking: - - the specific challenge friction/opportunity, - - how the idea guides user action or perception, - - expected UX improvement. -- Keep ideas practical, non-generic, and directly relevant to the described product context. - -FORMAT -Return exactly this structure: - - - -[Main user interactions/functions required by the challenge] - - - -1. [Affordance idea] - [Brief explanation] -2. [Affordance idea] - [Brief explanation] -3. [Affordance idea] - [Brief explanation] -4. [Affordance idea] - [Brief explanation] -5. [Affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Perceived affordance idea] - [Brief explanation] -2. [Perceived affordance idea] - [Brief explanation] -3. [Perceived affordance idea] - [Brief explanation] -4. [Perceived affordance idea] - [Brief explanation] -5. [Perceived affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Signifier idea] - [Brief explanation] -2. [Signifier idea] - [Brief explanation] -3. [Signifier idea] - [Brief explanation] -4. [Signifier idea] - [Brief explanation] -5. [Signifier idea] - [Brief explanation] -[Optional additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 5 ideas in any required category. -- Explanations are missing for one or more ideas. -- No interaction analysis is provided before idea lists. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-implementation-notes/SKILL.md b/.opencode/skills/productize-implementation-notes/SKILL.md deleted file mode 100644 index 6da03e47..00000000 --- a/.opencode/skills/productize-implementation-notes/SKILL.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: productize-implementation-notes -description: >- - Running implementation-notes protocol for spec-driven builds. Use when the user asks the - agent to maintain implementation-notes.md or implementation-notes.html with decisions, - deviations, tradeoffs, open questions, and verification while implementing a feature, fix, - or product slice. ---- - - - -# Implementation Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `implementation-notes` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence - -Use this skill when implementation work needs a durable notes artifact that keeps -the user in the loop without stopping progress for every ambiguity. - -This is not a verbose work log. It records the meaningful places where the spec -was interpreted, narrowed, changed, or found incomplete. - -## Activation - -Activate alongside `$tdd`, `$eng-review`, `$qa`, or `$verification` when the user -asks for any of: - -- `implementation-notes.md` -- `implementation-notes.html` -- running implementation notes -- decisions the spec did not cover -- deviations from the spec -- tradeoffs made during implementation -- open questions to confirm after implementation - -Do not ask whether to create the file if the user already requested it. Create or -update the requested file and keep working. - -## File Selection - -- Use the exact path and format the user requested. -- If the user asks for notes but does not name a file, use `implementation-notes.md`. -- If the user asks for HTML, use `implementation-notes.html`. -- If an implementation-notes file already exists for the current task, update it - instead of overwriting useful existing context. - -## Update Cadence - -1. Create the notes file before or during the first implementation decision. -2. Update it when the implementation makes a non-obvious choice, interprets an - ambiguous spec line, departs from the spec, accepts a tradeoff, discovers an - open question, or changes verification scope. -3. Batch small related choices into one entry instead of writing noisy micro-logs. -4. Before claiming completion, do a final pass that aligns notes with the actual - diff, verification evidence, and unresolved questions. - -## What To Capture - -### Design Decisions - -Choices made where the spec was ambiguous or silent. - -Each entry should include: - -- decision -- reason -- spec basis, or `unspecified` -- impact - -### Deviations - -Intentional departures from the spec. - -Each entry should include: - -- requested behavior -- implemented behavior -- reason -- impact -- whether user confirmation is needed - -### Tradeoffs - -Alternatives considered and why the chosen path is better for this slice. - -Each entry should include: - -- chosen option -- alternatives considered -- why chosen -- cost or downside accepted - -### Open Questions - -Questions the user may want to confirm or revise. - -Each entry should include: - -- question -- why it matters -- current default assumption -- status: `needs-review`, `accepted-risk`, `resolved`, or `deferred` - -### Verification - -Evidence that proves the implementation and the notes are current. - -Include: - -- commands or checks run -- result -- coverage gaps -- behavior not tested - -## What Not To Capture - -- Every file edit. -- Internal reasoning or chain-of-thought. -- Obvious implementation details already specified. -- Secrets, credentials, private customer data, or raw logs with sensitive content. -- Generic progress narration that does not help the user review decisions. - -## Markdown Template - -Use this structure for Markdown notes: - -```markdown -# Implementation Notes - -## Spec Reference -[Feature, ticket, prompt, or artifact being implemented.] - -## Summary -[One paragraph describing how the implementation interprets the spec.] - -## Design Decisions -| Decision | Reason | Spec basis | Impact | -|---|---|---|---| - -## Deviations -| Requested | Implemented | Why | Impact | Confirmation | -|---|---|---|---|---| - -## Tradeoffs -| Choice | Alternatives | Why this path | Downside | -|---|---|---|---| - -## Open Questions -| Question | Why it matters | Current assumption | Status | -|---|---|---|---| - -## Verification -| Check | Result | Notes | -|---|---|---| -``` - -## HTML Template Rules - -For `implementation-notes.html`, produce a single self-contained HTML file: - -- embedded CSS and JavaScript only -- no external assets or remote dependencies unless explicitly requested -- semantic headings and landmarks -- responsive layout -- decision cards or tables for scanability -- status chips for `needs-review`, `accepted-risk`, `resolved`, and `deferred` -- a clear verification section near the bottom -- optional filters, collapsible detail, or copy buttons only when they help review - -Recommended HTML sections: - -1. **Header**: spec reference, implementation status, last updated, owner if known. -2. **Decision Dashboard**: counts for decisions, deviations, tradeoffs, open questions. -3. **Design Decisions**: cards or table with reason, spec basis, and impact. -4. **Deviations**: requested vs implemented, why, impact, confirmation status. -5. **Tradeoffs**: comparison table with accepted downside. -6. **Open Questions**: status and current default assumption. -7. **Verification**: commands/checks, results, and gaps. - -## Route Internally - -- `$tdd` -- `$eng-review` -- `$qa` -- `$verification` -- `$docs` -- `$release` - -## Required Output - -Return: - -1. **Notes File**: path, format, and whether it was created or updated. -2. **Captured Decisions**: decisions, deviations, tradeoffs, and open questions added. -3. **Spec Impact**: what downstream product, design, eng, QA, release, docs, or DX work may change. -4. **Verification Linkage**: checks run, gaps, and whether the notes match the final implementation. -5. **Next Review**: user confirmations or gate follow-ups needed. diff --git a/.opencode/skills/productize-industry-trend-strategy/SKILL.md b/.opencode/skills/productize-industry-trend-strategy/SKILL.md deleted file mode 100644 index 28c42dff..00000000 --- a/.opencode/skills/productize-industry-trend-strategy/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: productize-industry-trend-strategy -description: >- - Industry trend strategy. Use when the user needs a product workflow for product strategy - related to industry trend strategy. Trigger terms: strategy, competitive-analysis, - positioning, decision-making. ---- - - - -# Industry trend strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `industry-trend-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Industry trend strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INDUSTRY}} -- {{TREND}} -- {{COMPANY}} -- {{GOAL}} - - -GOAL -Produce a high-quality deliverable for: Industry trend strategy. -Success metric: -- Produces a grounded industry + trend analysis tied to company strengths and goal. -- Proposes at least three distinct strategies with actionable steps. -- Summarizes how strategies leverage strengths to achieve the goal. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{INDUSTRY}}`, `{{TREND}}`, `{{COMPANY}}`, and `{{GOAL}}`; if critical data is missing, state assumptions explicitly. -- Provide a concise industry + trend analysis and a focused company strengths assessment. -- Propose at least 3 distinct strategies aligned to strengths and goal. -- Each strategy must include name, description, alignment, contribution to goal, challenges, and action steps. -- Keep recommendations specific and actionable, not generic. - -FORMAT -Return exactly this structure: - - -[Industry + trend analysis and company strength assessment] - - - -1. [Strategy name] - - Description: [What it is] - - Alignment: [Company strengths leveraged] - - Contribution to goal: [How it advances the goal] - - Challenges: [Risks/obstacles] - - Action steps: [Concrete steps] -2. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -3. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -[Optional additional strategies] - - - -[Summary emphasizing how strategies leverage strengths to capitalize on the trend and achieve the goal] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 strategies are provided. -- Strategies lack alignment to company strengths or contribution to goal. -- Action steps are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md b/.opencode/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md deleted file mode 100644 index 500376d5..00000000 --- a/.opencode/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-influence-strategies-from-cialdini-s-7-principles -description: >- - Influence strategies from Cialdini's 7 principles. Use when the user needs a product - workflow for stakeholder management related to influence strategies from cialdini's 7 - principles. Trigger terms: influence, cialdini, stakeholder-management. ---- - - - -# Influence strategies from Cialdini's 7 principles - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `influence-strategies-from-cialdini-s-7-principles` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Influence strategies from Cialdini's 7 principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INFLUENCE_TARGET}} -- {{INFLUENCE_GOAL}} - - -GOAL -Produce a high-quality deliverable for: Influence strategies from Cialdini's 7 principles. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate influence ideas tailored to `{{INFLUENCE_TARGET}}` and `{{INFLUENCE_GOAL}}`. -- Provide at least one specific, actionable, ethical idea for each Cialdini principle: -- Reciprocity -- Liking -- Unity -- Authority -- Social Proof -- Consistency -- Scarcity -- For each idea, include a clear strategy and rationale tied to the target context and goal. -- Use professional, non-manipulative tactics that create value for both sides. - -FORMAT -Return exactly this structure: - - - -Name of the principle -Detailed description of the strategy or tactic -Explanation of why this idea would be effective for the given target and goal - -(Repeat this structure for each of the seven principles) - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Not all seven principles are covered, or principles are duplicated while another is missing. -- Strategies are generic, unethical/manipulative, or not tied to the target and goal. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-innovation-decision-making-heuristics/SKILL.md b/.opencode/skills/productize-innovation-decision-making-heuristics/SKILL.md deleted file mode 100644 index 710886c0..00000000 --- a/.opencode/skills/productize-innovation-decision-making-heuristics/SKILL.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -name: productize-innovation-decision-making-heuristics -description: >- - Design tailored decision-making heuristics for uncertain innovation work. Use when the user - needs simple decision rules for product bets, discovery, investment, pivot, prioritization, - or opportunity selection in noisy and changing contexts. ---- - - - -# Innovation Decision Making Heuristics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovation-decision-making-heuristics` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop - -Use this skill when a team needs a practical decision rule, not a one-off recommendation. -The output should help the team decide repeatedly under uncertainty while avoiding arbitrary -or off-the-shelf rules. - -## Decision-Making Principles - -- Heuristics are useful shortcuts when the environment is noisy, dynamic, uncertain, or - time-sensitive and more information does not necessarily clarify direction. -- Heuristics fail when applied blindly, when nuance matters, or when the environment is stable - enough for more complete analysis. -- Effective heuristics should come from the user's real business challenge, constraints, - evidence, and observed feedback. -- A good heuristic makes tradeoffs explicit: speed versus accuracy, exploration versus focus, - safety versus moonshot, and learning versus commitment. -- Heuristics must be reviewed and refined through practical experience. - -## Workflow - -1. Identify the recurring decision type and the context in which it appears. -2. Classify the environment: noisy/dynamic/uncertain, stable, time-sensitive, multi-factor, - politically loaded, or high-stakes irreversible. -3. Define what the heuristic should optimize: learning, speed, risk control, focus, upside, - user value, revenue, retention, or strategic fit. -4. Identify where naive heuristics could fail. -5. Create 3-5 tailored decision rules with explicit triggers and exceptions. -6. Add a feedback loop so the rule can improve after use. - -## Output Contract - -Return: - -```markdown -# Innovation Decision Making Heuristics - -## 1. Recurring Decision -Decision type: -Who decides: -Frequency: -Time pressure: -Stakes: - -## 2. Decision Environment -Context: -Noise / uncertainty: -Information quality: -Reversibility: -Stable analysis possible: - -## 3. What The Rules Should Optimize -Primary objective: -Secondary objective: -Tradeoff to accept: -Tradeoff to avoid: - -## 4. Heuristic Failure Risks -Where shortcuts help: -Where shortcuts fail: -Bias risks: -Escalation or sunk-cost risk: - -## 5. Tailored Decision Rules -Rule 1: -Use when: -Exception: -Evidence needed: - -Rule 2: -Use when: -Exception: -Evidence needed: - -Rule 3: -Use when: -Exception: -Evidence needed: - -## 6. Feedback And Refinement -Signal to track: -Review cadence: -Who updates the rule: -When to retire the rule: -``` - -## Failure Modes - -- Provides generic principles instead of concrete decision rules. -- Creates rules that ignore the user's actual uncertainty, constraints, and feedback loops. -- Treats heuristics as always good or always bad rather than context-dependent. -- Omits exceptions and review mechanisms. diff --git a/.opencode/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md b/.opencode/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md deleted file mode 100644 index fe4b11dc..00000000 --- a/.opencode/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-project-parameters-and -description: >- - Innovative idea generation from project parameters and constraints. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, - product-management, osborn-checklist. ---- - - - -# Innovative idea generation from project parameters and constraints - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-project-parameters-and` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from project parameters and constraints**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_TYPE}} -- {{GOALS}} -- {{BUDGET}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from project parameters and constraints". -Success metric: -- Produces concrete, non-generic ideas that fit project type, goals, and budget. -- Uses structured creativity analysis (including Osborn checklist) to move beyond obvious solutions. -- Final ideas are immediately actionable with clear execution steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_TYPE}}`, `{{GOALS}}`, and `{{BUDGET}}`; if details are missing, state assumptions explicitly. -- Provide exactly 5 banal ideas to avoid and explain why each is weak. -- Define problem context including timeframe, target audience, and situation. -- Break down problem into objective, constraints, measurable success criteria, challenges, and deeper considerations. -- Analyze each chunk with explicit link to goals and budget feasibility. -- Include both creator and consumer perspectives. -- Apply Osborn checklist categories with project-relevant outputs: - - other uses, adaptations, modifications, magnification, minification, substitutions, rearrangements, reversals, combinations. -- Final ideas must be actionable for an individual, feasible under budget, and include step-by-step instructions plus application context. - -FORMAT -Return exactly this structure: - - - -1. [Banal idea] - [Why to avoid] -2. [Banal idea] - [Why to avoid] -3. [Banal idea] - [Why to avoid] -4. [Banal idea] - [Why to avoid] -5. [Banal idea] - [Why to avoid] - - - -[Clearly define the problem or situation] - - - -[Break down the problem into key aspects] - - - -[Provide in-depth analysis of each problem chunk] - - - -[Describe creator and consumer perspectives] - - - -- Other uses: [Ideas] -- Adaptations: [Ideas] -- Modifications: [Ideas] -- Magnification: [Ideas] -- Minification: [Ideas] -- Substitutions: [Ideas] -- Rearrangements: [Ideas] -- Reversals: [Ideas] -- Combinations: [Ideas] - - - -1. [Idea title] - - Specific guidance: [What to do] - - Steps: [Step-by-step] - - Where/how to apply: [Context/channel/tool] - - Budget fit: [How it stays within budget] -[Repeat for additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `banal_ideas` does not contain exactly 5 items. -- One or more Osborn checklist categories are missing. -- Final ideas are not actionable step-by-step or are not aligned to budget/goals. -- Output is generic or repeats clichรฉ ideas without meaningful differentiation. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md b/.opencode/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 3a22d36f..00000000 --- a/.opencode/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-structured-brainstorming -description: >- - Innovative idea generation from structured brainstorming techniques. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, - creativity, product-discovery, problem-solving. ---- - - - -# Innovative idea generation from structured brainstorming techniques - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from structured brainstorming techniques**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from structured brainstorming techniques". -Success metric: -- Produces a structured ideation session using free association, mind mapping, SCAMPER, and bias checks. -- Generates non-obvious, high-potential ideas grounded in the topic. -- Outputs clear top ideas with rationale and a concise synthesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run a complete structured ideation flow: - - free association (4-6 rounds), - - mind map (3-4 levels), - - SCAMPER exploration (2-3 rounds across shortlisted branches), - - bias check, - - top-idea selection and rationale. -- Avoid clichรฉd or overhyped ideas; prioritize specificity and novelty. -- Ensure top ideas are distinct from one another and clearly connected to generated branches. -- Keep outputs practical enough to be explored/prototyped next. - -FORMAT -Return exactly this structure: - - - -[4-6 rounds of free associations tied to `{{TOPIC}}`] - - - -[Mind map with 3-4 branching levels derived from free associations] - - - -1. [Branch] -2. [Branch] -3. [Branch] - - - -[2-3 rounds applying SCAMPER prompts to shortlisted branches] - - - -- Anchoring check: [Findings/adjustment] -- Status quo check: [Findings/adjustment] -- Groupthink check: [Findings/adjustment] - - - -1. [Idea 1] -2. [Idea 2] -3. [Idea 3] - - - -1. [Why idea 1 is powerful and non-obvious] -2. [Why idea 2 is powerful and non-obvious] -3. [Why idea 3 is powerful and non-obvious] - - - - -1. [Idea 1]: [Rationale] -2. [Idea 2]: [Rationale] -3. [Idea 3]: [Rationale] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `freeassociation` has fewer than 4 rounds or more than 6 rounds. -- `mindmap` does not show 3-4 levels of branching. -- `scamper` does not include at least 2 rounds. -- `top_ideas` does not contain exactly 3 distinct ideas. -- Rationales are generic and do not explain non-obvious value. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md b/.opencode/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 0ccf894a..00000000 --- a/.opencode/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -name: productize-innovative-product-ideas-from-structured-brainstorming -description: >- - Innovative product ideas from structured brainstorming. Use when the user needs a product - workflow for ideation & creativity related to innovative product ideas from structured - brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, - product-management. ---- - - - -# Innovative product ideas from structured brainstorming - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-product-ideas-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative product ideas from structured brainstorming**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative product ideas from structured brainstorming". -Success metric: -- Produces a complete structured brainstorming session from divergence to convergence. -- Generates non-obvious product ideas grounded in the topic and validated via bias checks. -- Returns exactly 3 top ideas with clear innovation rationale in abstract terms. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run all stages: free association, mind map, SCAMPER expansion, bias check, top-idea selection, summary. -- Avoid banal, overhyped, or clichรฉd outputs. -- Top ideas must be described abstractly; do not use specific tech buzzwords such as `AI`, `blockchain`, or `VR`. -- Ensure ideas are distinct and traceable to earlier brainstorming artifacts. - -FORMAT -Return exactly this structure: - - - - -1. [Word or phrase] -2. [Word or phrase] -... -[Total 8-10 items] - - - -[Topic] -- [Main branch 1] - - [Sub-branch 1a] - - [Sub-branch 1b] -- [Main branch 2] - - [Sub-branch 2a] - - [Sub-branch 2b] -- [Main branch 3] - - [Sub-branch 3a] - - [Sub-branch 3b] -[At least 3 main branches; each with 2-3 sub-branches] - - - -- Branch: [Name] - - Technique 1: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] - - Technique 2: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] -[Repeat for 3 branches] - - - -- Bias: [Name] - - Evidence in ideas: [How it appears] - - Countermeasure: [Concrete action] -[At least 1 bias] - - - -1. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -2. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -3. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] - - - -[Brief recap of process and why final ideas are stronger after SCAMPER and bias checks] - - - - -FAILURE -- Root tag `` or any required sub-tag is missing, malformed, or incomplete. -- `free_association` has fewer than 8 or more than 10 items. -- `mind_map` has fewer than 3 main branches or insufficient sub-branches. -- `scamper` does not cover 3 branches with 2 techniques each. -- `top_ideas` does not contain exactly 3 ideas. -- Top ideas include banned specific-technology terms (`AI`, `blockchain`, `VR`). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-interactive-intake-for-ost-inputs/SKILL.md b/.opencode/skills/productize-interactive-intake-for-ost-inputs/SKILL.md deleted file mode 100644 index 7353afd5..00000000 --- a/.opencode/skills/productize-interactive-intake-for-ost-inputs/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: productize-interactive-intake-for-ost-inputs -description: >- - Interactive intake for OST inputs. Use when the user needs a product workflow for user - research related to interactive intake for ost inputs. Trigger terms: user-research, ost, - continuous-discovery. ---- - - - -# Interactive intake for OST inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `interactive-intake-for-ost-inputs` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Interactive intake for OST inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Interactive intake for OST inputs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Act as an intake orchestrator for downstream OST inputs. -- Parse existing user-provided context first, then ask only missing critical questions. -- Collect and normalize exactly four variables: -- `{{business_outcome}}`: one concise, outcome-focused sentence (no solution wording). -- `{{journey_nodes_as_list}}`: JSON array of distinct journey moments (not features). -- `{{interview_transcripts_or_story_snippets}}`: markdown snippets with attribution and timestamps when available. -- `{{constraints_or_principles}}`: short markdown list/sentence or `None stated`. -- Apply quality guards: -- Reframe solution-flavored outcomes into measurable outcomes. -- Rephrase feature-like nodes into moments in time. -- Add minimal attribution labels when transcript context is sparse. -- Stop only when all four fields are present, clear, distinct, normalized, and confirmed. - -FORMAT -Return exactly this structure: - -{{business_outcome}}: [one concise, outcome-focused sentence] - -{{journey_nodes_as_list}}: ["[Moment 1]", "[Moment 2]", "[Moment 3]"] - -{{interview_transcripts_or_story_snippets}}: -[markdown transcript/snippets with speaker labels and timestamps if available] - -{{constraints_or_principles}}: -[short markdown list or sentence; if none provided, write "None stated"] - -FAILURE -- Any of the four required variables is missing or malformed. -- `{{business_outcome}}` is solution-flavored or not measurable/outcome-oriented. -- `{{journey_nodes_as_list}}` is not valid JSON array syntax or contains features instead of moments. -- Interview material lacks usable attribution/context when source data allows it. -- Constraints field is omitted instead of explicitly set to `None stated`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-lean-canvas/SKILL.md b/.opencode/skills/productize-lean-canvas/SKILL.md deleted file mode 100644 index b3a18d33..00000000 --- a/.opencode/skills/productize-lean-canvas/SKILL.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -name: productize-lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- - - - -# Lean Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `lean-canvas` -- **Lifecycle**: Think -- **Category**: Business Model -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.opencode/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md b/.opencode/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md deleted file mode 100644 index 672e4be9..00000000 --- a/.opencode/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-limit-based-product-strategy-from-problem-to-execution-plan -description: >- - Limit-based product strategy from problem to execution plan. Use when the user needs a - product workflow for product strategy related to limit-based product strategy from problem - to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, - structured-thinking. ---- - - - -# Limit-based product strategy from problem to execution plan - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `limit-based-product-strategy-from-problem-to-execution-plan` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Limit-based product strategy from problem to execution plan**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Produce a high-quality deliverable for: Limit-based product strategy from problem to execution plan. -Success metric: -- Applies the full Limit-Based Product Thinking framework end-to-end. -- Produces concrete milestones, levers, assumptions, and a phased execution plan. -- Keeps outputs grounded in the provided problem statement. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM_STATEMENT}}`; if critical details are missing, state assumptions explicitly. -- Follow all 7 framework steps in order. -- Provide quantified convergence milestones at 10%, 25%, 50%, 75%, 90% with dates or triggers. -- Identify levers to accelerate convergence and explicitly name the top 1โ€“2 highest impact moves. -- List critical assumptions with validation methods. -- Provide a 3-phase plan (Foundation, Acceleration, Optimization) with timelines and resource guidance. - -FORMAT -Return exactly this structure: - - -1. Growth Variable: [Your identified variable] - -2. Limit State Description: - [Your vivid description of the fully mature state] - -3. Core Properties of the Limit: - [List of key features and interactions] - -4. Convergence Estimate: - [Growth curve and milestones] - -5. Acceleration Strategies: - [Prioritized list of levers to steepen the curve] - -6. Critical Assumptions: - [List of assumptions with validation methods] - -7. Product Vision and Execution: - Vision Statement: [One-sentence summary] - Roadmap: [Major milestones and timelines] - 3-Phase Plan: [Brief outline of each phase] - Resource Allocation: [Key recommendations] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Convergence milestones are missing required percentages or triggers/dates. -- Acceleration strategies lack prioritized top 1โ€“2 levers. -- Assumptions lack validation methods. -- 3-phase plan is missing or not sequenced. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md b/.opencode/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md deleted file mode 100644 index 110f89a8..00000000 --- a/.opencode/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: productize-low-frequency-to-power-user-transition-strategy -description: >- - Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow - for product strategy related to low-frequency-to-power-user transition strategy. Trigger - terms: product-strategy, engagement, activation, retention. ---- - - - -# Low-Frequency-to-Power-User Transition Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `low-frequency-to-power-user-transition-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Low-Frequency-to-Power-User Transition Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_DESCRIPTION}} -- {{CURRENT_USE_CASE}} -- {{TARGET_USE_CASE}} - - -GOAL -Produce a high-quality deliverable for: Low-Frequency-to-Power-User Transition Strategy. -Success metric: -- Produces a concrete transition plan from low-frequency to high-frequency usage. -- Aligns strategy to current and target use cases with explicit behavioral gaps. -- Includes metrics, timeline, and rollout/education plans grounded in the inputs. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_DESCRIPTION}}`, `{{CURRENT_USE_CASE}}`, and `{{TARGET_USE_CASE}}`; if information is missing, state assumptions explicitly. -- Identify the behavioral gap between current and target usage. -- Provide step-by-step transition plan, education/onboarding, and communication strategy. -- Include rollout plan, key metrics, and timeline for measurement. -- Keep recommendations specific and grounded in the provided context. - -FORMAT -Return exactly this structure: - - -1. Current Use Case Analysis: - [Provide a brief analysis of the current low-frequency use case] - -2. Target Use Case Analysis: - [Provide a brief analysis of the target high-frequency use case] - -3. User Behavior and Needs: - [Summarize key insights about user behavior and needs] - -4. Transition Strategy: - a. Feature Introduction Plan: - [Outline the step-by-step plan for introducing new features] - b. User Education and Onboarding: - [Describe the approach for educating users about the new use case] - c. Communication Strategy: - [Outline the key messages and channels for communicating the benefits] - d. Gradual Rollout Plan: - [Describe the approach for gradually introducing new functionality] - -5. Implementation and Measurement: - a. Key Metrics: - [List the primary metrics to track for measuring success] - b. Timeline: - [Provide a high-level timeline for implementation and evaluation] - c. Feedback and Iteration: - [Describe the plan for collecting user feedback and making improvements] - -6. Potential Challenges and Mitigation Strategies: - [Identify potential obstacles and propose solutions] - -7. Conclusion: - [Summarize the key points of the transition strategy and its potential impact] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Behavioral gap or barriers are not explicitly identified. -- Metrics or timeline are missing. -- Strategies are generic or not tied to the given use cases. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-managerial-finance-dcf/SKILL.md b/.opencode/skills/productize-managerial-finance-dcf/SKILL.md deleted file mode 100644 index 6b191136..00000000 --- a/.opencode/skills/productize-managerial-finance-dcf/SKILL.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -name: productize-managerial-finance-dcf -description: >- - Productize Finance engine for time value of money, DCF, NPV, IRR, payback, free cash flow, - terminal value, project valuation, mutually exclusive investments, and whether growth - creates or destroys value. ---- - - - -# Managerial Finance DCF - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `managerial-finance-dcf` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings - -## Purpose - -Core investment-decision skill for evaluating projects and cash-flow streams. -Use it when comparing investments, building free cash flow forecasts, calculating -NPV/IRR/payback, estimating terminal value, or judging whether growth creates value. - -## Core Formulas - -- `FV_t = C_0 * (1 + r)^t` -- `PV = C_t / (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(C_t / (1 + r)^t)` -- `NPV with TV = -I_0 + sum(FCF_t / (1 + r)^t) + TV_N / (1 + r)^N` -- `0 = -I_0 + sum(C_t / (1 + IRR)^t)` -- `Profitability Index = PV of Future Cash Flows / Initial Investment` -- `FCF = EBIT * (1 - T_c) + Depreciation - CapEx - Delta NWC` -- `NOPAT = EBIT * (1 - T_c)` -- `TV_N = FCF_{N+1} / (r - g)` with `r > g` -- `ROIC = NOPAT / Invested Capital` -- `Reinvestment Rate = (CapEx - Depreciation + Delta NWC) / NOPAT` -- `g = ROIC * Reinvestment Rate` - -## Decision Rules - -- Independent projects: accept if `NPV > 0`; reject if `NPV < 0`. -- Mutually exclusive projects: choose the highest NPV. -- IRR supports the decision, but warn when cash flows change sign more than once, - projects differ in scale or timing, or multiple/no real IRRs exist. -- Growth creates value only when `ROIC > WACC`; it destroys value when `ROIC < WACC`. - -## Required Functions - -Use `$finance-modeling-kernel` functions for PV/FV, streams, NPV, IRR, payback, -discounted payback, annuities, perpetuities, free cash flow, terminal value, -ROIC, reinvestment rate, and sustainable growth. - -## Required Validation - -- Warn if comparing undiscounted cash flows across time. -- Warn if terminal growth exceeds long-run economic growth. -- Reject `g >= r` in growing perpetuity. -- Warn if IRR conflicts with NPV. -- Warn if payback is used as the final decision rule. -- Warn if sunk costs, financing cash flows, non-incremental overhead, cannibalization, - or opportunity cost are mishandled. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Make NPV the primary investment decision rule. diff --git a/.opencode/skills/productize-map-power-dynamics-before-meetings/SKILL.md b/.opencode/skills/productize-map-power-dynamics-before-meetings/SKILL.md deleted file mode 100644 index 6bfe5f9f..00000000 --- a/.opencode/skills/productize-map-power-dynamics-before-meetings/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-map-power-dynamics-before-meetings -description: >- - Map power dynamics before meetings. Use when the user needs a product workflow for - stakeholder management related to map power dynamics before meetings. Trigger terms: - stakeholders, power-dynamics, meetings, communication. ---- - - - -# Map power dynamics before meetings - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `map-power-dynamics-before-meetings` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Map power dynamics before meetings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DETAILS}} -- {{ATTENDEES_INFO}} - - -GOAL -Produce a high-quality deliverable for: "Map power dynamics before meetings". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{MEETING_DETAILS}}` and `{{ATTENDEES_INFO}}` to map meeting-specific power dynamics. -- Identify formal hierarchy, informal influence signals, alliances/conflicts, and each attendee's stake in outcomes. -- Rank attendees by influence in this meeting context. -- Identify decision-makers, influencers, power imbalances, and likely conflict points. -- Provide actionable strategies to navigate dynamics during the meeting. -- If information is insufficient for any claim, explicitly state the uncertainty. - -FORMAT -Return exactly this structure: - - - -[List attendees in order of influence, with brief notes on their power sources] - - - -[Bullet points of important observations about the power dynamics] - - - -[Bullet points of strategies to navigate the power dynamics effectively] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Influence ranking is not meeting-contextual or lacks power-source rationale. -- Recommendations are generic or not tied to identified dynamics/conflicts. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md b/.opencode/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md deleted file mode 100644 index 1cb24d45..00000000 --- a/.opencode/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-market-opportunities-from-jobs-to-be-done-market-canvas -description: >- - Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product - workflow for product strategy related to market opportunities from jobs-to-be-done market - canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, - product-strategy. ---- - - - -# Market opportunities from Jobs-to-be-Done market canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunities-from-jobs-to-be-done-market-canvas` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path - -Use this skill to run the Productize prompt contract for **Market opportunities from Jobs-to-be-Done market canvas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_OR_SERVICE}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Market opportunities from Jobs-to-be-Done market canvas. -Success metric: -- Guides the user through all 8 JTBD canvas steps with clear prompts. -- Keeps responses tied to provided `{{USER_INPUT}}` and the product context. -- Ends with a concise summary prompt that reflects the completed canvas. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_OR_SERVICE}}` and `{{USER_INPUT}}`; if context is missing, state assumptions explicitly. -- Ask for user input at each of the 8 JTBD canvas steps. -- Provide a brief explanation before each stepโ€™s prompt. -- Require the user to answer within the specified `` tags. -- End by requesting a `` that synthesizes the full canvas. -- Remind the user to use `{{USER_INPUT}}` when answering. - -FORMAT -Return exactly this structure: - - -[Prompt + explanation for Traditional Market Definition] - - - -[Prompt + explanation for Job Executor Determination] - - - -[Prompt + explanation for Abstracted Job Executor] - - - -[Prompt + explanation for Job Executor Documentation] - - - -[Prompt + explanation for Product Function Analysis] - - - -[Prompt + explanation for Complementary Product Analysis] - - - -[Prompt + explanation for Job Statement Abstraction] - - - -[Prompt + explanation for Final Job Documentation] - - - -[Prompt asking the user to summarize the completed canvas] - - -FAILURE -- Any required step tag in `FORMAT` is missing, malformed, or incomplete. -- Prompts do not request user responses within the correct `` tags. -- User is not reminded to use `{{USER_INPUT}}` for responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-market-opportunity/SKILL.md b/.opencode/skills/productize-market-opportunity/SKILL.md deleted file mode 100644 index bf55ae97..00000000 --- a/.opencode/skills/productize-market-opportunity/SKILL.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -name: productize-market-opportunity -description: >- - Identify, compare, and choose market opportunities for a venture, product, technology, or - innovation. Use when a founder, entrepreneur, product team, or innovator is choosing which - market to enter, picking a primary customer segment, evaluating whether a technology has - better use cases, deciding whether to pivot, comparing growth options, framing a venture for - investors, or asking variants of "which market should I target", "is this the right - opportunity", "where should I focus", "should I pivot", or "what else could this be used - for". Produces filled-in opportunity canvases for the Market Opportunity Set, Attractiveness - Map, Focus Portfolio Map, and Focus Strategy. Default to this skill when the question is - where to play rather than how to play. ---- - - - -# Market Opportunity - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunity` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market Opportunity venture brief with target segment, wedge, assumptions, and validation path - -Create the complete four-part market opportunity artifact set for choosing where a -venture, technology, product, or innovation should play. - -Use neutral terms such as `canvas`, `opportunity artifact`, `strategy surface`, or the -artifact names below. - -## Argument Hint - -`` - -## Usage - -```text -/market-opportunity $ARGUMENTS -``` - -## Required Artifacts - -For any complete request, create all four artifacts unless the user explicitly asks for -only one: - -1. **Opportunity Overview Canvas**: the three-part overview with opportunity set, - attractiveness map, and focus portfolio map. -2. **Opportunity Set Builder**: abilities -> applications -> customers -> market - opportunities. -3. **Attractiveness Evaluator**: potential and challenge ratings for each market - opportunity. -4. **Focus Portfolio Planner**: primary market opportunity, backup options, growth - options, and pursue/keep/store decisions. - -Load `references/canonical-canvases.md` before creating blank templates, filled -templates, printable layouts, or tables. It defines the exact fields and structure. - -Load `references/rating-and-decision-rules.md` before rating opportunities, -classifying map zones, or recommending primary, backup, and growth options. - -Load `references/output-formats.md` when the user asks for Markdown, HTML, PDF, -slides, visual canvases, or printable templates. - -## Workflow - -### 1. Establish the Input Mode - -Determine whether the user wants: - -- **Blank canvas set**: empty structured artifacts for a team to fill in. -- **Filled canvas set**: completed artifacts from a venture/product/technology idea. -- **Opportunity review**: critique or improve an existing opportunity set. -- **Strategy decision**: choose the primary opportunity and portfolio options. -- **Printable artifact**: create visual HTML/PDF/slide-ready canvases. - -If context is missing, ask only for the smallest useful missing piece: - -- The venture, product, technology, or core ability. -- Candidate applications. -- Candidate customer groups. -- Existing evidence for demand, market size, economics, implementation, timing, and risks. - -### 2. Generate the Market Opportunity Set - -Identify the venture's core abilities or technological elements first. Describe them -independent of the envisioned product. - -Then generate combinations: - -```text -market opportunity = application + customer segment -``` - -Segment customers precisely. Avoid broad labels like "enterprises" or "consumers" -unless the user has no better information. - -### 3. Evaluate Attractiveness - -For each market opportunity, rate: - -- **Potential** - - Compelling reason to buy. - - Market volume. - - Economic viability. -- **Challenge** - - Implementation obstacles. - - Time to revenue. - - External risks. - -Use the four-level rating scale: - -```text -Low / Mid / High / Super High -``` - -Then place each opportunity on the attractiveness map: - -- **Gold Mine** -- **Quick Win** -- **Moon Shot** -- **Questionable** - -### 4. Design the Focus Portfolio - -Choose one **Primary Market Opportunity** based on attractiveness and strategic fit. - -For other attractive opportunities, assess relatedness to the primary opportunity: - -- **Product relatedness**: shared technological competences, required resources, - and necessary networks. -- **Market relatedness**: shared customer values and benefits, sales channels, and - word-of-mouth paths. - -Classify each option: - -- **Growth Option**: attractive and useful for creating additional value. -- **Backup Option**: attractive and does not share major risks with the primary path. -- **Storage**: documented but not worth active preservation now. - -Make one of three action decisions for each option: - -- Pursue now. -- Keep open. -- Place in storage. - -The final strategy must keep at least one credible backup option and one credible -growth option open unless the available evidence makes that impossible. If impossible, -say what evidence or opportunity generation is missing. - -### 5. Tie Strategy to Execution - -For completed strategy outputs, include implications for: - -- Product and technology modularity. -- IP and defensibility. -- Hiring and capability development. -- Stakeholder and investor alignment. -- Brand and market communication. -- Experiments, assumptions, and learning loops. -- Business Model Canvas, Value Proposition Canvas, and Lean Startup integration when - the user asks for execution planning. - -## Output Rules - -- Preserve the canonical field names and rating scales from the reference files. -- Do not collapse the framework into SWOT, generic market sizing, or a feature - prioritization matrix. -- Be explicit about assumptions and evidence gaps. -- Use tables for editable outputs. -- For visual outputs, use the same four-artifact structure and neutral artifact titles. -- Do not copy long passages from source PDFs. Use the exact operational labels and - schemas, with original wording for explanations and recommendations. diff --git a/.opencode/skills/productize-market-opportunity/references/canonical-canvases.md b/.opencode/skills/productize-market-opportunity/references/canonical-canvases.md deleted file mode 100644 index a3c436db..00000000 --- a/.opencode/skills/productize-market-opportunity/references/canonical-canvases.md +++ /dev/null @@ -1,234 +0,0 @@ -# Canonical Market Opportunity Canvases - -Use these four canvases as the canonical output surfaces. Use neutral artifact names in -user-facing output. - -## 1. Opportunity Overview Canvas - -Purpose: show the entire flow from opportunity generation to attractiveness placement -to focus portfolio decision. - -Required fields: - -- Name. -- Date. -- Title: `Market Opportunity Overview`. -- Market opportunity definition: `application + customer`. -- Left panel: **Market Opportunity Set**. -- Middle panel: **Attractiveness Map**. -- Right panel: **Focus Portfolio Map**. - -### Market Opportunity Set Panel - -Contains market opportunity cards generated from: - -```text -application + customer = market opportunity -``` - -Each card should have: - -| Field | Description | -|---|---| -| ID | Short stable label such as MO-1, MO-2, MO-3 | -| Application | What the core ability enables | -| Customer segment | Who needs that application | -| Market opportunity | Combined application + customer | - -### Attractiveness Map Panel - -Axes: - -| Axis | Direction | Rating Levels | -|---|---|---| -| Potential | vertical | Low, Mid, High, Super High | -| Challenge | horizontal | Low, Mid, High, Super High | - -Zones: - -| Zone | Meaning | -|---|---| -| Gold Mine | High potential with relatively low challenge | -| Quick Win | Lower potential with relatively low challenge | -| Moon Shot | High potential with high challenge | -| Questionable | Lower potential with high challenge | - -### Focus Portfolio Map Panel - -Nested decision areas: - -| Area | Meaning | -|---|---| -| Pursue now | Active focus or active parallel pursuit | -| Keep open | Preserve option value without fully committing | -| Place in storage | Document but do not actively preserve now | - -Cards placed here must identify whether they are primary, backup, growth, or storage -options. - -## 2. Opportunity Set Builder - -Purpose: generate market opportunities by combining core abilities, applications, and -customer segments. - -Required fields: - -- Name. -- Date. -- Title: `Generate Your Market Opportunity Set`. -- Core abilities or technological elements. -- Applications. -- Customers. -- Market opportunities. - -### Core Abilities Table - -List the venture's core abilities or technological elements. Characterize each by -function and properties, independent from the envisioned product. - -| Ability ID | Core Ability or Technological Element | Function | Key Properties | Evidence / Notes | -|---|---|---|---|---| -| A1 | | | | | -| A2 | | | | | -| A3 | | | | | -| A4 | | | | | - -### Market Opportunity Generation Table - -Use each row to combine an application with a customer segment. - -| Opportunity ID | Ability ID(s) | Application | Customer Segment | Finer Customer Segmentation | Market Opportunity | -|---|---|---|---|---|---| -| MO-1 | | | | | | -| MO-2 | | | | | | -| MO-3 | | | | | | - -Generation prompts: - -- Which applications can the core abilities offer? -- Which customers may need each application? -- Can the customer group be segmented more precisely? -- Which combinations should be evaluated next? - -## 3. Attractiveness Evaluator - -Purpose: evaluate each market opportunity by potential and challenge, then place it -on the attractiveness map. - -Required fields: - -- Name. -- Date. -- Title: `Evaluate Market Opportunity Attractiveness`. -- Market Opportunity. -- Potential. -- Challenge. -- Overall Potential. -- Overall Challenge. -- Attractiveness Map zone. - -Use this canvas once for every market opportunity being evaluated. - -### Potential Ratings - -| Potential Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Compelling Reason to Buy | Unmet need; effective solution; better than current solutions | Low / Mid / High / Super High | | -| Market Volume | Current market size; expected growth | Low / Mid / High / Super High | | -| Economic Viability | Margins (value vs. cost); customers' ability to pay; customer stickiness | Low / Mid / High / Super High | | - -### Challenge Ratings - -| Challenge Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Implementation Obstacles | Product development difficulties; sales and distribution difficulties; funding challenges | Low / Mid / High / Super High | | -| Time to Revenue | Development time; time between product and market readiness; length of sales cycle | Low / Mid / High / Super High | | -| External Risks | Competitive threat; third-party dependencies; barriers to adoption | Low / Mid / High / Super High | | - -### Overall Placement - -| Market Opportunity | Overall Potential | Overall Challenge | Map Zone | Rationale | -|---|---|---|---|---| -| | Low / Mid / High / Super High | Low / Mid / High / Super High | Gold Mine / Quick Win / Moon Shot / Questionable | | - -## 4. Focus Portfolio Planner - -Purpose: design the focus strategy around one primary market opportunity while -preserving backup and growth options. - -Required fields: - -- Name. -- Date. -- Title: `Design Your Focus Strategy`. -- Primary Market Opportunity. -- Other attractive market opportunities. -- Product relatedness. -- Market relatedness. -- Suitable as backup option. -- Suitable as growth option. -- Action decision: pursue now, keep open, or place in storage. - -### Step I: Choose Primary Market Opportunity - -Choose the primary market opportunity based on the attractiveness map. - -| Primary Market Opportunity | Attractiveness Map Position | Why This Is Primary | Main Evidence | Main Risks | -|---|---|---|---|---| -| | | | | | - -### Step II: Examine Other Attractive Opportunities - -For each other attractive market opportunity, compare it with the primary opportunity. - -| Option ID | Market Opportunity | Product Relatedness | Product Relatedness Rationale | Market Relatedness | Market Relatedness Rationale | Risk Overlap With Primary | -|---|---|---|---|---|---|---| -| MO-2 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-3 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-4 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | - -Product relatedness asks how much the products share: - -- Technological competences. -- Required resources. -- Necessary networks. - -Market relatedness asks how much the customers share: - -- Values and benefits. -- Sales channels. -- Word-of-mouth paths. - -### Step III: Classify and Decide - -Use this table to mark whether each option is suitable as backup, growth, both, or -neither, then decide what to do with it. - -| Option ID | Market Opportunity | Backup Option? | Growth Option? | Action | Rationale | -|---|---|---|---|---|---| -| MO-2 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-3 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-4 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | - -Definitions: - -- **Backup Option**: an attractive market opportunity that does not share major risks - with the primary market opportunity and can support a change in direction. -- **Growth Option**: an attractive market opportunity that can create additional value - if the primary opportunity succeeds. - -Strategy rule: - -- Keep at least one Backup Option open. -- Keep at least one Growth Option open. -- Decide whether any option is worth pursuing now. -- Place the rest in storage. - -### Final Focus Strategy Summary - -| Category | Market Opportunity | Decision | Why | -|---|---|---|---| -| Primary | | Pursue now | | -| Backup | | Keep open / Pursue now | | -| Growth | | Keep open / Pursue now | | -| Storage | | Place in storage | | diff --git a/.opencode/skills/productize-market-opportunity/references/output-formats.md b/.opencode/skills/productize-market-opportunity/references/output-formats.md deleted file mode 100644 index ee145a61..00000000 --- a/.opencode/skills/productize-market-opportunity/references/output-formats.md +++ /dev/null @@ -1,143 +0,0 @@ -# Output Formats - -Use the same canonical four-artifact structure in every format. Use neutral artifact -names in titles and headings. - -## Markdown Blank Canvas Set - -Use when the user wants editable text tables. - -Required sections: - -```markdown -# Market Opportunity - -## 1. Opportunity Overview Canvas -[overview tables] - -## 2. Opportunity Set Builder -[blank abilities and opportunity generation tables] - -## 3. Attractiveness Evaluator -[one blank evaluator per opportunity, or reusable blank evaluator] - -## 4. Focus Portfolio Planner -[blank primary, relatedness, backup/growth, and action decision tables] -``` - -## Markdown Filled Canvas Set - -Use when the user provides a venture, technology, product, or opportunity set. - -Required sections: - -```markdown -# Market Opportunity: [Venture/Product] - -## 1. Opportunity Overview Canvas -- Market opportunity cards. -- Attractiveness placements. -- Focus portfolio decisions. - -## 2. Opportunity Set Builder -- Core abilities. -- Applications. -- Customer segments. -- Generated market opportunities. - -## 3. Attractiveness Evaluator -- One evaluation table per selected market opportunity. -- Overall potential, overall challenge, and map zone. - -## 4. Focus Portfolio Planner -- Primary market opportunity. -- Option comparison by product and market relatedness. -- Backup/growth classification. -- Pursue now / keep open / place in storage decisions. - -## Strategy Implications -- Product/technology modularity. -- IP and defensibility. -- Hiring/capability needs. -- Stakeholder and investor alignment. -- Brand and communication implications. -- Experiments and next evidence to collect. -``` - -## Visual or Printable Canvas - -Use when the user asks for printable templates, visual canvases, an HTML file, a PDF, -or a slide-ready output. - -Requirements: - -- Produce four separate pages or sections. -- Preserve the same layout logic: - - Overview: three panels side by side. - - Opportunity Set Builder: abilities at top; applications and customers below. - - Attractiveness Evaluator: potential on left, challenge on right, overall ratings at - the bottom. - - Focus Portfolio Planner: primary opportunity at top, option columns below, relatedness - rows, backup/growth rows, action rows at bottom. -- Use neutral artifact titles. -- Include `Name` and `Date` fields when producing a printable artifact. -- Include editable blank spaces or filled content depending on the requested mode. - -Recommended visual names: - -| Original Function | Use This Title | -|---|---| -| Full opportunity overview | Market Opportunity Overview | -| Generate opportunity set | Opportunity Set Builder | -| Evaluate attractiveness | Market Opportunity Attractiveness | -| Design focus strategy | Focus Strategy Planner | - -## Compact Decision Memo - -Use when the user wants a concise strategic answer rather than the full canvas set. - -Required sections: - -```markdown -## Recommendation -[Primary market opportunity and why] - -## Opportunity Portfolio -| Category | Opportunity | Decision | Why | - -## Key Ratings -| Opportunity | Potential | Challenge | Zone | - -## Risks and Open Assumptions -[Most important evidence gaps] - -## Next Tests -[Lean experiments or research needed] -``` - -## Spreadsheet-Friendly Format - -Use when the user wants to paste into Sheets/Excel. - -Create four CSV-style tables: - -1. `opportunity_set` -2. `attractiveness_ratings` -3. `map_placements` -4. `focus_portfolio` - -Minimum columns: - -```text -opportunity_set: -opportunity_id,ability_ids,application,customer_segment,finer_segment,market_opportunity - -attractiveness_ratings: -opportunity_id,potential_compelling_reason,potential_market_volume,potential_economic_viability,overall_potential,challenge_implementation,challenge_time_to_revenue,challenge_external_risks,overall_challenge,evidence_notes - -map_placements: -opportunity_id,overall_potential,overall_challenge,map_zone - -focus_portfolio: -opportunity_id,role,product_relatedness,market_relatedness,risk_overlap,backup_option,growth_option,action,rationale -``` diff --git a/.opencode/skills/productize-market-opportunity/references/rating-and-decision-rules.md b/.opencode/skills/productize-market-opportunity/references/rating-and-decision-rules.md deleted file mode 100644 index fdfe3093..00000000 --- a/.opencode/skills/productize-market-opportunity/references/rating-and-decision-rules.md +++ /dev/null @@ -1,250 +0,0 @@ -# Rating and Decision Rules - -Use these rules to keep opportunity ratings consistent. - -## Rating Scale - -Use only these four levels: - -```text -Low / Mid / High / Super High -``` - -For challenge dimensions, higher means more difficult, slower, riskier, or more -resource-intensive. Low challenge is good. - -## Potential Ratings - -### Compelling Reason to Buy - -Rate based on: - -- Strength of unmet need. -- Whether the solution effectively addresses the need. -- Whether it is better than current alternatives. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak pain, unclear need, or little advantage over alternatives | -| Mid | Recognizable need but limited urgency or differentiation | -| High | Clear need, strong solution fit, meaningful advantage | -| Super High | Urgent need, strong willingness to switch or buy, clear superiority | - -### Market Volume - -Rate based on: - -- Current market size. -- Expected growth. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Small or shrinking reachable market | -| Mid | Meaningful niche or uncertain growth | -| High | Large reachable market or strong growth | -| Super High | Very large market with strong growth and credible reach | - -### Economic Viability - -Rate based on: - -- Margins: value created versus cost to deliver. -- Customers' ability to pay. -- Customer stickiness. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak margins, low willingness or ability to pay, low retention potential | -| Mid | Economics may work but are not yet proven | -| High | Attractive value/cost relationship and credible willingness to pay | -| Super High | Strong margins, high willingness to pay, strong retention or lock-in | - -## Challenge Ratings - -### Implementation Obstacles - -Rate based on: - -- Product development difficulties. -- Sales and distribution difficulties. -- Funding challenges. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Straightforward product, go-to-market, and funding path | -| Mid | Some execution difficulty, but manageable | -| High | Significant product, distribution, or funding obstacles | -| Super High | Very difficult execution path or major resource gap | - -### Time to Revenue - -Rate based on: - -- Development time. -- Gap between product readiness and market readiness. -- Length of sales cycle. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Revenue can plausibly arrive quickly | -| Mid | Moderate path to revenue | -| High | Long development, readiness, or sales cycle | -| Super High | Very long or uncertain time to revenue | - -### External Risks - -Rate based on: - -- Competitive threat. -- Third-party dependencies. -- Barriers to adoption. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Limited external risk or manageable dependencies | -| Mid | Some competitive, dependency, or adoption risk | -| High | Serious external risks that could block progress | -| Super High | External risks may dominate the opportunity | - -## Overall Potential and Challenge - -Do not compute mechanically unless the user asks for numeric scoring. Use evidence and -judgment. - -Default aggregation: - -- Overall Potential should reflect the weakest critical potential dimension. A huge - market is not enough if there is no compelling reason to buy. -- Overall Challenge should reflect the hardest blocking challenge. A simple build is - not enough if revenue requires a multi-year sales cycle. - -If using numeric support: - -```text -Low = 1 -Mid = 2 -High = 3 -Super High = 4 -``` - -Use the rounded average as a starting point, then adjust for blockers and explain the -adjustment. - -## Attractiveness Map Zone Rules - -| Overall Potential | Overall Challenge | Zone | -|---|---|---| -| High or Super High | Low or Mid | Gold Mine | -| Low or Mid | Low or Mid | Quick Win | -| High or Super High | High or Super High | Moon Shot | -| Low or Mid | High or Super High | Questionable | - -Interpretation: - -- **Gold Mine**: strongest candidate for primary focus. -- **Quick Win**: potentially useful for learning, early traction, or stepping stones. -- **Moon Shot**: valuable but difficult; may require capital, patience, or unique assets. -- **Questionable**: weak candidate unless strategic reasons or new evidence change the view. - -## Primary Market Opportunity Rules - -Select the primary opportunity by weighing: - -- Attractiveness map zone. -- Strength of evidence. -- Founder/team fit. -- Ability to test assumptions. -- Strategic control and defensibility. -- Fit with resource constraints. - -Default preference: - -1. Gold Mine with strong evidence. -2. Gold Mine with evidence gaps but testable assumptions. -3. Quick Win if it creates learning, revenue, or capability for a larger path. -4. Moon Shot only if the upside is large enough and the team has unusual advantages. -5. Questionable only if the user explicitly has strategic reasons. - -## Backup Option Rules - -A backup option should be attractive and should not share major risks with the primary -opportunity. - -Good backup options often differ on: - -- Customer segment. -- Sales channel. -- Adoption barrier. -- Regulatory pathway. -- Revenue model. -- Critical dependency. - -Do not label an option as backup merely because it is related. If it fails for the same -reason the primary fails, it is not a useful backup. - -## Growth Option Rules - -A growth option should be attractive and should let the venture create additional value -after or alongside the primary opportunity. - -Good growth options often share: - -- Technology. -- Capabilities. -- Customer relationships. -- Distribution. -- Brand credibility. -- Data or network effects. - -High relatedness makes a growth option more plausible. Very low relatedness usually -means the opportunity is diversification, not a near-term growth option. - -## Action Decision Rules - -### Pursue Now - -Use when: - -- The option is primary, or -- The option is highly attractive, resources permit parallel pursuit, and pursuing it - does not dilute the primary focus. - -### Keep Open - -Use when: - -- The option has strategic value as backup or growth. -- The cost of preserving it is modest. -- It requires monitoring, lightweight experiments, modular design choices, IP claims, - partner conversations, or relationship maintenance. - -### Place in Storage - -Use when: - -- The option is not attractive enough now. -- The opportunity is too unrelated or costly to preserve. -- Evidence is too weak. -- It is worth remembering but not worth spending active effort on. - -## Evidence Discipline - -For each rating, distinguish: - -- Evidence: facts, interviews, data, observed behavior, signed interest, market numbers. -- Assumptions: plausible but unvalidated beliefs. -- Unknowns: missing information that could change the rating. - -When evidence is weak, phrase the output as a hypothesis and propose the next test. diff --git a/.opencode/skills/productize-market-orientation-audit/SKILL.md b/.opencode/skills/productize-market-orientation-audit/SKILL.md deleted file mode 100644 index 914f16eb..00000000 --- a/.opencode/skills/productize-market-orientation-audit/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: productize-market-orientation-audit -description: >- - Audit whether an organization is truly market oriented using intelligence generation, - intelligence dissemination, and responsiveness. Use for customer-centricity, marketing - culture, organizational diagnosis, market sensing, and scorecard-based improvement plans. ---- - - - -# Market Orientation Audit - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-orientation-audit` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user wants to diagnose how well an organization senses markets, shares customer/competitor insight internally, and acts on that insight. - -Do not use it for brand health, campaign evaluation, or product-market fit unless the question is specifically about organizational market orientation. - -## Core Model - -Market orientation is an organization-wide culture and operating system for creating customer value. It has three dimensions: - -- **Intelligence generation**: how the organization detects customer, competitor, collaborator, technology, and regulatory changes. -- **Intelligence dissemination**: how quickly and effectively insight spreads across functions. -- **Responsiveness**: how fast and well the organization acts on market intelligence. - -## Scorecard - -Use a 1-5 scale: - -- 5 = Strongly agree -- 4 = Agree -- 3 = Neither agree nor disagree -- 2 = Disagree -- 1 = Strongly disagree - -Each dimension has 8 items. Dimension scoring: - -- 29-40 = High -- 20-28 = Moderate -- 8-19 = Low - -Total scoring: - -- 86-120 = High -- 60-85 = Moderate -- 24-59 = Low - -### Intelligence Generation - -1. We have interdepartmental meetings at least once a quarter to discuss market trends and developments. -2. We are quick to detect fundamental shifts in our industry, such as competition, technology, or regulation. -3. We periodically review the likely effect of environmental changes on customers. -4. We are fast to detect changes in customer product and service preferences. -5. People discuss customers' future needs with other functions or departments. -6. We do a lot of in-house market research. -7. We survey key customers at least once a year to assess product and service quality. -8. We meet key clients at least once a year to learn what products or services they will need in the future. - -### Intelligence Dissemination - -1. When something important happens to a major customer or market, the whole business knows quickly. -2. When one department learns something important about competitors, it quickly alerts other departments. -3. We would never ignore changes in customer product or service needs. -4. When customers want a product or service modification, involved teams make concerted efforts to respond. -5. We periodically review product or service development to ensure it aligns with key customer needs. -6. We have communication systems that speed dissemination of important customer-related information. -7. All functions and departments are responsive to each other's needs and requests. -8. When a customer complains or gives feedback, we quickly share it with anyone who can act on it. - -### Responsiveness - -1. It takes very little time to decide how to respond to competitor product or service changes. -2. We can implement new ideas, marketing plans, product redesigns, or service enhancements in a timely fashion. -3. Several functions periodically plan responses to changes in the business environment. -4. If a major competitor aggressively targeted a key customer, we would consider a response immediately. -5. We quickly act on customer complaints and feedback. -6. Customer-facing employees have latitude to solve customer problems without excessive red tape. -7. People here tend to talk more about opportunities than problems. -8. When we see a new opportunity to create customer value, we act quickly. - -## Workflow - -1. Collect scores from the user or run a facilitated self-assessment. -2. Compute dimension totals and total score. -3. Identify the weakest dimension and the lowest individual items. -4. Diagnose root causes across incentives, structure, tooling, decision rights, data access, rituals, and culture. -5. Translate findings into operating changes, not just research recommendations. -6. Define a 30/60/90-day improvement plan and measurement cadence. - -## Output - -Return: - -- **Score Summary**: dimension scores, total score, high/moderate/low rating. -- **Pattern Diagnosis**: what the scores imply about market sensing, sharing, and action. -- **Lowest Items**: the specific behaviors causing the largest gap. -- **Organizational Hurdles**: structure, incentives, data, rituals, authority, culture. -- **Improvement Plan**: 30/60/90-day actions. -- **Operating Metrics**: indicators to track improvement. - -## Quality Bar - -- Do not equate customer-facing friendliness with market orientation. -- Treat market orientation as cross-functional. -- Separate collecting insight from acting on insight. -- Recommend concrete operating changes, not generic "talk to customers more" advice. diff --git a/.opencode/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md b/.opencode/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md deleted file mode 100644 index ca888dbb..00000000 --- a/.opencode/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: productize-market-requirements-from-strategic-market-inputs -description: >- - Market requirements from strategic market inputs. Use when the user needs a product workflow - for product strategy related to market requirements from strategic market inputs. Trigger - terms: product-management, market-research, strategy, MRD. ---- - - - -# Market requirements from strategic market inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-requirements-from-strategic-market-inputs` -- **Lifecycle**: Strategize -- **Category**: Discovery -- **Primary artifact**: Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Market requirements from strategic market inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MARKET_INDUSTRY}} -- {{PROBLEM_UNMET_NEED}} -- {{TARGET_USER_BUYER}} -- {{CURRENT_ALTERNATIVES}} -- {{COMPANY_ROLE_VISION_ADVANTAGE}} -- {{EXTERNAL_FACTORS}} -- {{OUTPUT_REQUEST}} - - -GOAL -Produce a high-quality deliverable for: Market requirements from strategic market inputs. -Success metric: -- Gathers required MRD inputs via a structured question flow. -- Produces decision-ready MRD sections only after the user confirms โ€œReady to draft.โ€ -- Keeps analysis concise, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; ask one question at a time until the user says **โ€œReady to draft.โ€** -- Do not draft any MRD section before the user explicitly says **โ€œReady to draft.โ€** -- After the user selects the output (Aโ€“D), produce that section only and pause for feedback. -- Use links for citations; state assumptions explicitly. -- No emojis. No JSON output. - -FORMAT -Return exactly this structure: - - -Letโ€™s co-create a Market Requirements Document. Iโ€™ll ask a few questions to gather context and then generate a draft. First up: What market or industry are you exploring? - - - -[Your single next question based on the most recent answer] - - -[When user says โ€œReady to draft,โ€ respond with exactly one of the requested MRD sections using the MRD Output Format headings.] - -FAILURE -- Output drafts MRD sections before user says โ€œReady to draft.โ€ -- More than one question is asked at a time. -- Output does not follow the selected section from Aโ€“D. -- Missing citations/assumptions where needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-market-sizing/SKILL.md b/.opencode/skills/productize-market-sizing/SKILL.md deleted file mode 100644 index 6467fec0..00000000 --- a/.opencode/skills/productize-market-sizing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, - market-entry upside, or investor-ready opportunity size. ---- - - - -# Market Sizing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-sizing` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.opencode/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md b/.opencode/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md deleted file mode 100644 index be955241..00000000 --- a/.opencode/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: productize-mece-analysis-and-logical-tree-from-list-items -description: >- - MECE analysis and logical tree from list items. Use when the user needs a product workflow - for decision making related to mece analysis and logical tree from list items. Trigger - terms: pm, decision-making, mece, structured-thinking, frameworks. ---- - - - -# MECE analysis and logical tree from list items - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `mece-analysis-and-logical-tree-from-list-items` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **MECE analysis and logical tree from list items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{LIST_OF_ITEMS}} - - -GOAL -Evaluate `LIST_OF_ITEMS` for MECE quality and produce a logical tree that resolves overlaps/gaps. -Success metric: -- Clearly assesses mutual exclusivity and collective exhaustiveness. -- Identifies concrete overlaps and coverage gaps (if any). -- Produces a coherent tree structure reflecting corrected grouping logic. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Test pairwise overlap (mutual exclusivity). - 2. Test coverage gaps (collective exhaustiveness). - 3. Propose corrected structure and hierarchy. -- Keep conclusions grounded in the provided list; avoid unrelated frameworks unless necessary. -- If ambiguity exists in item definitions, state assumptions explicitly. -- Provide concise rationale, not hidden/internal chain-of-thought. - -FORMAT -Return exactly this structure: - - - -[State whether items are mutually exclusive, with specific overlap examples where relevant] - - -[State whether items are collectively exhaustive, with specific gap examples where relevant] - - -[Concise list of overlap issues and/or coverage gaps] - - - - -[MECE status: Fully MECE | Not MECE | Partially MECE] - -[Hierarchical tree showing corrected structure and item placement] - - - -FAILURE -- Required schema sections are missing or malformed. -- Mutual exclusivity or collective exhaustiveness assessment is absent. -- Logical tree is missing, unclear, or inconsistent with analysis findings. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md b/.opencode/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md deleted file mode 100644 index 917e0acf..00000000 --- a/.opencode/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: productize-meeting-agendas-from-meeting-descriptions -description: >- - Meeting agendas from meeting descriptions. Use when the user needs a product workflow for - project management related to meeting agendas from meeting descriptions. Trigger terms: - meetings, facilitation, planning, productivity. ---- - - - -# Meeting agendas from meeting descriptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-agendas-from-meeting-descriptions` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Meeting agendas from meeting descriptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DESCRIPTION}} - - -GOAL -Produce a high-quality deliverable for: "Meeting agendas from meeting descriptions". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a meeting preparation output from `{{MEETING_DESCRIPTION}}` that includes: -- A clear purpose statement for the meeting. -- A structured agenda with allocated time per topic and key questions per topic. -- A practical process/flow for running the meeting to achieve the stated purpose. -- Internally reason from meeting goals, stakeholders, and constraints; return only the required final sections. - -FORMAT -Return exactly this structure: - - -[Clear and concise purpose statement] - - - -1. [Agenda Topic 1] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -2. [Agenda Topic 2] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -[Additional agenda topics] - - - -[Suggested process and flow for the meeting] - - -FAILURE -- Any required section (``, ``, ``) is missing or materially incomplete. -- Agenda items do not include both time allocation and key questions. -- Meeting flow/process is generic and not tied to the stated purpose. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md b/.opencode/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md deleted file mode 100644 index bbf05acf..00000000 --- a/.opencode/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: productize-meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- - - - -# Meeting Outcome Planning and Stakeholder Alignment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-outcome-planning-and-stakeholder-alignment` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md b/.opencode/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md deleted file mode 100644 index 60997def..00000000 --- a/.opencode/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-meeting-summaries-from-meeting-transcript-ideas-framework -description: >- - Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a - product workflow for presentation & communication related to meeting summaries from meeting - transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, - note-taking. ---- - - - -# Meeting summaries from meeting transcript (IDEAS framework) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-summaries-from-meeting-transcript-ideas-framework` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Meeting summaries from meeting transcript (IDEAS framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Meeting summaries from meeting transcript (IDEAS framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are tasked with summarizing a meeting using the IDEAS framework. This framework helps organize the key points of a meeting into five categories: Insights, Decisions, Engagements, Actions, and Summary. Here's the meeting transcript you need to analyze: - - -{{MEETING_TRANSCRIPT}} - - -Please carefully read and analyze the meeting transcript. Then, summarize the meeting using the IDEAS framework as follows: - -1. Insights: Identify and list the main insights or important realizations that emerged during the meeting. -2. Decisions: Note any decisions that were made during the meeting. -3. Engagements: List any tasks or responsibilities that were assigned to specific individuals or teams. -4. Actions: Highlight any immediate actions that need to be taken as a result of the meeting. -5. Summary: Provide a brief overall summary of the meeting's impact and significance. - -When writing your summary, please be concise and focused. Aim to capture the most important points rather than trying to include every detail. Use bullet points for each category to make the summary easy to read and understand. - -Present your summary using the following format, enclosed in XML tags: - -Remember to focus on the most significant and relevant information for each category. Your goal is to provide a clear, organized, and useful summary of the meeting using the IDEAS framework. - - -FORMAT -Return exactly this structure: - - - -โ€ข [List insights here] - - - -โ€ข [List decisions here] - - - -โ€ข [List engagements here] - - - -โ€ข [List actions here] - - - -[Write a brief overall summary here] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-message-framing-and-comms-plan-designer/SKILL.md b/.opencode/skills/productize-message-framing-and-comms-plan-designer/SKILL.md deleted file mode 100644 index 8cc37534..00000000 --- a/.opencode/skills/productize-message-framing-and-comms-plan-designer/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-message-framing-and-comms-plan-designer -description: >- - Message Framing & Comms Plan Designer. Use when the user needs a product workflow for - stakeholder management related to message framing & comms plan designer. Trigger terms: - communication, executive-communication, messaging, stakeholder-management. ---- - - - -# Message Framing & Comms Plan Designer - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `message-framing-and-comms-plan-designer` -- **Lifecycle**: Design -- **Category**: Marketing -- **Primary artifact**: Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Message Framing & Comms Plan Designer**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Message Framing & Comms Plan Designer. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use provided facts, audience, goal, and writing sample to design a message framing and communication plan. -- Provide 2-3 viable framing options, each with a one-line rationale tied to credibility, logic, and audience emotion. -- Produce two concise drafts in the user's natural tone: -- `ICs` draft with context, changes, actions, and timeline (`<=180` words). -- `Execs` draft with BLUF, risks/asks, and decision needed (`<=120` words). -- Include a strong subject/headline and two Slack snippets (announcement + reminder). -- Provide a mini comms plan with channel sequence, owner, timing, emphasis, and CTA. -- Include a `What to Omit` noise-reduction list and exactly 3 success signals. - -FORMAT -Return exactly this structure: - -Frames & Rationale -- [Frame 1]: [one-line rationale] -- [Frame 2]: [one-line rationale] -- [Frame 3 if used]: [one-line rationale] - -Draft for ICs -Subject/Headline: [text] -[ICs draft <=180 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Draft for Execs -Subject/Headline: [text] -[Execs draft <=120 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Mini Comms Plan -| Step | Channel | Owner | Timing | Emphasis | CTA | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -What to Omit -- [item] - -Success Signals -1. [signal] -2. [signal] -3. [signal] - -FAILURE -- Any required section is missing or materially incomplete. -- ICs draft exceeds 180 words or Execs draft exceeds 120 words. -- Missing subject/headline or missing either Slack snippet type (announcement/reminder). -- Comms plan table is missing required columns or sequence logic. -- Success Signals are not exactly three measurable indicators. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/.opencode/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md b/.opencode/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md deleted file mode 100644 index 364641cd..00000000 --- a/.opencode/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- - - - -# Metric drops diagnosis with rigorous stepwise decomposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- **Lifecycle**: Strategize -- **Category**: Analytics -- **Primary artifact**: Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/.opencode/skills/productize-metrics-review/SKILL.md b/.opencode/skills/productize-metrics-review/SKILL.md deleted file mode 100644 index ce1527cf..00000000 --- a/.opencode/skills/productize-metrics-review/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-metrics-review -description: >- - Review and analyze product metrics with trend analysis and actionable insights. Use when - running a weekly, monthly, or quarterly metrics review, investigating a spike or drop, - comparing against targets, or turning raw numbers into a scorecard with recommended actions. ---- - - - -# Metrics Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metrics-review` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Metric scorecard, trend diagnosis, and recommended action plan - -Review product metrics, identify trends, and surface action-oriented insights. - -## Argument Hint - -`
` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/plugins/productize-all/skills/productize-explore-data/agents/openai.yaml b/plugins/productize-all/skills/productize-explore-data/agents/openai.yaml deleted file mode 100644 index d287e9a2..00000000 --- a/plugins/productize-all/skills/productize-explore-data/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Explore Data" - short_description: "Profile and explore a dataset to understand its shape, quality, and patterns. Use when encountering a new table or..." - brand_color: "#0F766E" - default_prompt: "Use $productize-explore-data with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md b/plugins/productize-all/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md deleted file mode 100644 index 58de7bfa..00000000 --- a/plugins/productize-all/skills/productize-feature-impact-models-from-kpis-and-assumptions/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: productize-feature-impact-models-from-kpis-and-assumptions -description: >- - Feature impact models from KPIs and assumptions. Use when the user needs a product workflow - for business analysis related to feature impact models from kpis and assumptions. Trigger - terms: pm, business-analysis, financial-modeling, kpi-impact. ---- - - - -# Feature impact models from KPIs and assumptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-impact-models-from-kpis-and-assumptions` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Feature impact models from KPIs and assumptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_INFO}} -- {{KPIS_TO_ESTIMATE}} - - -GOAL -Produce a high-quality deliverable for: Feature impact models from KPIs and assumptions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Build a procedural task list that covers: - - key assumptions, - - baseline metric calculations, - - per-KPI impact estimation, - - sensitivity analysis. -- Execute the tasks and show calculations step by step using explicit formulas/equations. -- For each KPI, provide: - - point estimate, - - assumptions and calculations used, - - brief explanation of feature-to-KPI impact mechanism. -- If information is missing, state what is missing, add a reasonable assumption, label it clearly, and proceed. -- Prioritize transparent math and reasoning over spreadsheet-like verbosity. -- Keep conclusions focused on executive decision-making (investment impact, major drivers, key risks). - - -FORMAT -Return exactly this structure: - - - -[List the procedural tasks used to build the model] - - - -[Step-by-step calculations, formulas, assumptions, and point estimates for each KPI] - - - -[Feature overview, KPI estimate table/list, key assumptions, sensitivity-analysis takeaways, and executive conclusions] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-feature-impact-models-from-kpis-and-assumptions/agents/openai.yaml b/plugins/productize-all/skills/productize-feature-impact-models-from-kpis-and-assumptions/agents/openai.yaml deleted file mode 100644 index 29a3659c..00000000 --- a/plugins/productize-all/skills/productize-feature-impact-models-from-kpis-and-assumptions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Feature impact models from KPIs and assumptions" - short_description: "Feature impact models from KPIs and assumptions. Use when the user needs a product workflow for business analysis..." - brand_color: "#0D9488" - default_prompt: "Use $productize-feature-impact-models-from-kpis-and-assumptions with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md b/plugins/productize-all/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md deleted file mode 100644 index ba3f5a3b..00000000 --- a/plugins/productize-all/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- - - - -# Feature results analysis from draft to final report - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-results-analysis-from-draft-to-final-report` -- **Lifecycle**: Launch & Learn -- **Category**: Analytics -- **Primary artifact**: Feature results readout with iterate, rollback, kill, or scale recommendation - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-feature-results-analysis-from-draft-to-final-report/agents/openai.yaml b/plugins/productize-all/skills/productize-feature-results-analysis-from-draft-to-final-report/agents/openai.yaml deleted file mode 100644 index a9c1ce13..00000000 --- a/plugins/productize-all/skills/productize-feature-results-analysis-from-draft-to-final-report/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Feature results analysis from draft to final report" - short_description: "Feature results analysis from draft to final report. Use when the user needs a product workflow for business..." - brand_color: "#0F766E" - default_prompt: "Use $productize-feature-results-analysis-from-draft-to-final-report with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-features-reframing-and-projects-shape-up/SKILL.md b/plugins/productize-all/skills/productize-features-reframing-and-projects-shape-up/SKILL.md deleted file mode 100644 index 0049fb31..00000000 --- a/plugins/productize-all/skills/productize-features-reframing-and-projects-shape-up/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: productize-features-reframing-and-projects-shape-up -description: >- - Features reframing and projects Shape Up. Use when the user needs a product workflow for - technical related to features reframing and projects shape up. Trigger terms: - product-strategy, shaping, scope-management, stakeholder-management, technical. ---- - - - -# Features reframing and projects Shape Up - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `features-reframing-and-projects-shape-up` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Features reframing and projects Shape Up**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_OR_PROJECT}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Features reframing and projects Shape Up. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reframe `{{FEATURE_OR_PROJECT}}` using Shape Up principles and provided `{{CONTEXT}}`. -- Provide a shaped work definition that is concrete enough for delivery but avoids build-phase implementation detail. -- Include: -- Appetite assessment (`1-2 weeks` or `6 weeks`) with rationale. -- Problem framing (problem-first, not solution-first). -- Boundary definition (in-scope / out-of-scope). -- Solution sketch at fat-marker level. -- Risks/rabbit holes and circuit-breakers. -- Explicit no-gos. -- Executive constraint language to secure scope commitment and prevent mid-cycle scope creep. -- Keep output focused on shaping quality, delivery constraints, and stakeholder alignment. - -FORMAT -Return exactly this structure: - -Shape Up Reframe - -Appetite Assessment -- Recommended appetite: [1-2 weeks or 6 weeks] -- Why this appetite: [rationale] - -Problem Framing -- Core problem: [problem statement] -- Why this matters now: [impact/context] -- Success condition: [what success looks like] - -Boundary Definition -- In scope: - - [item] -- Out of scope: - - [item] - -Solution Sketching (Fat Marker Level) -- Key approach: [high-level approach] -- Main interaction/surface 1: [conceptual behavior] -- Main interaction/surface 2: [conceptual behavior] - -Risks and Rabbit Holes -- [risk/rabbit hole] -- Circuit-breaker: [constraint or stop-rule] - -No-gos -- [explicit exclusion] - -Executive Constraints -- Commitment language: [specific wording to secure scope agreement] -- Change-control rule: [how new requests are handled mid-cycle] -- Escalation path: [who decides if scope must change] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Output drifts into build-phase implementation details instead of shaping-level decisions. -- Boundaries/no-gos are vague or do not constrain scope. -- Executive constraint handling is missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-features-reframing-and-projects-shape-up/agents/openai.yaml b/plugins/productize-all/skills/productize-features-reframing-and-projects-shape-up/agents/openai.yaml deleted file mode 100644 index 572e3978..00000000 --- a/plugins/productize-all/skills/productize-features-reframing-and-projects-shape-up/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Features reframing and projects Shape Up" - short_description: "Features reframing and projects Shape Up. Use when the user needs a product workflow for technical related to..." - brand_color: "#334155" - default_prompt: "Use $productize-features-reframing-and-projects-shape-up with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/SKILL.md b/plugins/productize-all/skills/productize-finance-modeling-kernel/SKILL.md deleted file mode 100644 index 538d3739..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/SKILL.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: productize-finance-modeling-kernel -description: >- - Shared Productize Finance calculation and validation kernel for exact formulas, input - normalization, assumption checks, units, warnings, and acceptance-tested finance math used - by valuation, DCF, cost-of-capital, capital-structure, VC deal, and market-context skills. ---- - - - -# Finance Modeling Kernel - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `finance-modeling-kernel` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings - -## Purpose - -Shared calculation and validation library used by all Productize Finance skills. -Use this skill when a finance workflow needs exact formulas, normalized inputs, -assumption checks, error handling, units, or validation before making a recommendation. - -## Kernel Modules - -- `finance-modeling-kernel/time_value.py`: PV, FV, annuities, perpetuities, spot-rate streams. -- `finance-modeling-kernel/dcf.py`: NPV, IRR, payback, free cash flow, terminal value, ROIC, growth. -- `finance-modeling-kernel/returns.py`: realized returns, expected return, variance, volatility, covariance, correlation. -- `finance-modeling-kernel/risk.py`: portfolio variance, covariance, correlation, beta, regression beta. -- `finance-modeling-kernel/capm.py`: CAPM, unlevered beta, relevered beta. -- `finance-modeling-kernel/wacc.py`: WACC with market-value weights. -- `finance-modeling-kernel/apv.py`: tax shields and APV. -- `finance-modeling-kernel/valuation.py`: DCF valuation, terminal value, EV-to-equity bridge, multiples, sensitivities. -- `finance-modeling-kernel/capital_structure.py`: EV, equity value, leverage, MM, tax shields, APV. -- `finance-modeling-kernel/bond_math.py`: bond price, yield to maturity, current yield, credit spread. -- `finance-modeling-kernel/vc_method.py`: burn, runway, VC target multiple, pre/post-money, shares. -- `finance-modeling-kernel/cap_table.py`: fully diluted shares, ownership, dilution, cap table sum checks. -- `finance-modeling-kernel/convertible_notes.py`: note conversion amount, discount price, cap price, shares. -- `finance-modeling-kernel/safes.py`: SAFE conversion price, SAFE shares, post-money SAFE ownership. -- `finance-modeling-kernel/preferred_stock.py`: liquidation preference and preferred payoff waterfalls. -- `finance-modeling-kernel/option_pools.py`: investor-friendly and founder-friendly option pool math. -- `finance-modeling-kernel/market_context.py`: market cap, weights, listing changes, CAGR. -- `finance-modeling-kernel/validation.py`: shared validation errors and warning helpers. -- `finance-modeling-kernel/tests/`: acceptance tests for the minimum formula examples. - -## Finance Output Format - -All Productize Finance agents must return: - -1. **Inputs** -2. **Assumptions** -3. **Formula used** -4. **Calculation** -5. **Result** -6. **Interpretation** -7. **Warnings** - -## Global Guardrails - -1. Never compare cash flows at different dates without compounding or discounting. -2. Use market values, not book values, for valuation and WACC weights whenever possible. -3. Match discount rates to cash-flow risk. -4. Do not use a company WACC for a project with materially different risk. -5. Do not mix financing cash flows into operating free cash flow. -6. Use NPV as the primary investment decision rule. -7. Treat IRR, payback, and multiples as supporting tools, not final truth. -8. For VC deals, always state whether share counts are basic or fully diluted. -9. For option pools, always state whether the pool is investor-friendly or founder-friendly. -10. For convertible notes and SAFEs, always read the conversion definition before calculating. -11. For preferred stock, model the payoff waterfall, not only the ownership percentage. - -## Workflow - -1. Identify the finance problem and the cash-flow timing, units, currency, and risk basis. -2. Choose the exact module and function; do not invent ad hoc formulas when a kernel function exists. -3. Validate formula preconditions, especially `r > g`, positive denominators, share-count basis, and market-value weights. -4. Calculate transparently enough that the user can audit the math. -5. Return the standard Finance output format and warnings. - -## Acceptance Tests - -Run: - -```sh -python3 skills/finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py -``` - -The test suite covers DCF NPV, growing perpetuity, CAPM, WACC, VC target multiple, -post-money/pre-money, convertible note discount conversion, investor-friendly option -pool, and non-participating preferred payoff. diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/agents/openai.yaml b/plugins/productize-all/skills/productize-finance-modeling-kernel/agents/openai.yaml deleted file mode 100644 index 85559cfe..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Finance Modeling Kernel" - short_description: "Shared Productize Finance calculation and validation kernel for exact formulas, input normalization, assumption..." - brand_color: "#0369A1" - default_prompt: "Use $productize-finance-modeling-kernel with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py deleted file mode 100644 index 754f2374..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/apv.py +++ /dev/null @@ -1,10 +0,0 @@ -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py deleted file mode 100644 index bbbe83d7..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/bond_math.py +++ /dev/null @@ -1,36 +0,0 @@ -from validation import FinanceValidationError, require_positive - - -def bond_price(coupon, face_value, yield_to_maturity, periods): - if yield_to_maturity == 0: - return coupon * periods + face_value - return coupon * (1 - (1 + yield_to_maturity) ** (-periods)) / yield_to_maturity + face_value / (1 + yield_to_maturity) ** periods - - -def yield_to_maturity(price, coupon, face_value, periods, tolerance=1e-7, max_iterations=200): - require_positive("price", price) - low = -0.999999 - high = 1.0 - while bond_price(coupon, face_value, high, periods) > price and high < 1000: - high *= 2 - if high >= 1000: - raise FinanceValidationError("Yield to maturity could not be bracketed.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_price = bond_price(coupon, face_value, mid, periods) - if abs(mid_price - price) <= tolerance: - return mid - if mid_price > price: - low = mid - else: - high = mid - return (low + high) / 2 - - -def current_yield(annual_coupon, bond_price_value): - require_positive("bond_price", bond_price_value) - return annual_coupon / bond_price_value - - -def credit_spread(risky_yield, risk_free_yield): - return risky_yield - risk_free_yield diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py deleted file mode 100644 index 73d96466..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/cap_table.py +++ /dev/null @@ -1,19 +0,0 @@ -from validation import require_positive - - -def fully_diluted_shares(common=0, preferred_as_converted=0, options_issued=0, option_pool_unissued=0, warrants=0, convertibles=0): - return common + preferred_as_converted + options_issued + option_pool_unissued + warrants + convertibles - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares - - -def dilution(old_ownership_percentage, new_ownership_percentage): - require_positive("old_ownership_percentage", old_ownership_percentage) - return 1 - new_ownership_percentage / old_ownership_percentage - - -def cap_table_sums_to_100(ownership_percentages, tolerance=1e-6): - return abs(sum(ownership_percentages) - 1) <= tolerance diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py deleted file mode 100644 index e8e7565e..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capital_structure.py +++ /dev/null @@ -1,51 +0,0 @@ -from validation import require_positive - - -def enterprise_value(equity_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return equity_value + debt + preferred_stock + minority_interest - cash - nonoperating_assets - - -def equity_value_from_ev(enterprise_value_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def debt_to_equity(debt, equity): - require_positive("equity", equity) - return debt / equity - - -def debt_to_value(debt, equity): - require_positive("debt plus equity", debt + equity) - return debt / (debt + equity) - - -def degree_of_financial_leverage(ebit, interest): - require_positive("ebit minus interest", ebit - interest) - return ebit / (ebit - interest) - - -def wacc(equity, debt, cost_of_equity, cost_of_debt, tax_rate): - total = equity + debt - require_positive("debt plus equity", total) - return equity / total * cost_of_equity + debt / total * (1 - tax_rate) * cost_of_debt - - -def mm_value_no_taxes(unlevered_value): - return unlevered_value - - -def mm_cost_of_equity_no_taxes(unlevered_cost_of_capital, cost_of_debt, debt, equity): - require_positive("equity", equity) - return unlevered_cost_of_capital + debt / equity * (unlevered_cost_of_capital - cost_of_debt) - - -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py deleted file mode 100644 index 19a58da7..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/capm.py +++ /dev/null @@ -1,21 +0,0 @@ -from validation import require_positive - - -def capm_cost_of_equity(risk_free_rate, beta, market_risk_premium): - return risk_free_rate + beta * market_risk_premium - - -def unlever_beta(beta_l, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_l / (1 + (1 - tax_rate) * debt / equity) - - -def relever_beta(beta_u, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_u * (1 + (1 - tax_rate) * debt / equity) - - -def asset_beta_with_debt_beta(beta_equity, beta_debt, debt, equity, tax_rate=0): - require_positive("total capital", debt + equity) - tax_adjusted_debt = debt * (1 - tax_rate) - return (beta_equity * equity + beta_debt * tax_adjusted_debt) / (equity + tax_adjusted_debt) diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py deleted file mode 100644 index 9d05470a..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py +++ /dev/null @@ -1,27 +0,0 @@ -from validation import require_positive - - -def convertible_note_conversion_amount(principal, interest_rate, time, compounding_method="simple"): - if compounding_method == "simple": - return principal * (1 + interest_rate * time) - if compounding_method == "compound": - return principal * (1 + interest_rate) ** time - raise ValueError("compounding_method must be simple or compound.") - - -def convertible_note_discount_price(series_a_price, discount_rate): - return (1 - discount_rate) * series_a_price - - -def convertible_note_cap_price(valuation_cap, cap_share_count): - require_positive("cap_share_count", cap_share_count) - return valuation_cap / cap_share_count - - -def convertible_note_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def convertible_note_shares(conversion_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return conversion_amount / conversion_price diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py deleted file mode 100644 index 204cb98b..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py +++ /dev/null @@ -1,73 +0,0 @@ -from validation import FinanceValidationError, require_positive, require_rate_greater_than_growth - - -def npv(initial_investment, cash_flows, discount_rate): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def npv_with_terminal_value(initial_investment, fcfs, discount_rate, terminal_value): - return npv(initial_investment, fcfs, discount_rate) + terminal_value / (1 + discount_rate) ** len(fcfs) - - -def irr(cash_flows, tolerance=1e-7, max_iterations=200): - def value(rate): - return sum(cash_flow / (1 + rate) ** period for period, cash_flow in enumerate(cash_flows)) - - low = -0.999999 - high = 1.0 - low_value = value(low) - high_value = value(high) - while low_value * high_value > 0 and high < 1000: - high *= 2 - high_value = value(high) - if low_value * high_value > 0: - raise FinanceValidationError("IRR could not be bracketed; cash flows may have no real IRR or multiple IRRs.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_value = value(mid) - if abs(mid_value) <= tolerance: - return mid - if low_value * mid_value < 0: - high = mid - high_value = mid_value - else: - low = mid - low_value = mid_value - return (low + high) / 2 - - -def payback_period(cash_flows): - cumulative = 0 - for period, cash_flow in enumerate(cash_flows): - cumulative += cash_flow - if cumulative >= 0: - return period - return None - - -def discounted_payback_period(cash_flows, discount_rate): - discounted = [cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows)] - return payback_period(discounted) - - -def free_cash_flow(ebit, tax_rate, depreciation, capex, delta_nwc): - return ebit * (1 - tax_rate) + depreciation - capex - delta_nwc - - -def terminal_value_gordon(fcf_next, discount_rate, growth_rate): - require_rate_greater_than_growth(discount_rate, growth_rate, "discount_rate") - return fcf_next / (discount_rate - growth_rate) - - -def roic(nopat, invested_capital): - require_positive("invested_capital", invested_capital) - return nopat / invested_capital - - -def reinvestment_rate(capex, depreciation, delta_nwc, nopat): - require_positive("nopat", nopat) - return (capex - depreciation + delta_nwc) / nopat - - -def sustainable_growth(roic_value, reinvestment_rate_value): - return roic_value * reinvestment_rate_value diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py deleted file mode 100644 index 7596a040..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/market_context.py +++ /dev/null @@ -1,34 +0,0 @@ -from validation import require_positive - - -def market_cap(price, shares_outstanding): - return price * shares_outstanding - - -def market_weight(company_market_cap, total_market_cap): - require_positive("total_market_cap", total_market_cap) - return company_market_cap / total_market_cap - - -def index_weight(company_market_cap, index_total_market_cap): - require_positive("index_total_market_cap", index_total_market_cap) - return company_market_cap / index_total_market_cap - - -def global_lookthrough_weight(index_weight_value, index_share_of_country_market, country_share_of_world_market): - return index_weight_value * index_share_of_country_market * country_share_of_world_market - - -def change_in_listings(start_listings, end_listings): - return end_listings - start_listings - - -def percentage_change(start_value, end_value): - require_positive("start_value", start_value) - return end_value / start_value - 1 - - -def cagr(beginning_value, ending_value, years): - require_positive("beginning_value", beginning_value) - require_positive("years", years) - return (ending_value / beginning_value) ** (1 / years) - 1 diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py deleted file mode 100644 index e593de1a..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/option_pools.py +++ /dev/null @@ -1,22 +0,0 @@ -def investor_friendly_option_pool(existing_shares, investor_target_ownership, target_option_pool): - total_post_money_shares = existing_shares / (1 - investor_target_ownership - target_option_pool) - investor_shares = investor_target_ownership * total_post_money_shares - option_pool_shares = target_option_pool * total_post_money_shares - existing_holder_ownership = existing_shares / total_post_money_shares - return { - "total_post_money_shares": total_post_money_shares, - "investor_shares": investor_shares, - "option_pool_shares": option_pool_shares, - "existing_holder_ownership": existing_holder_ownership, - } - - -def founder_friendly_option_pool(existing_shares, investor_shares, target_option_pool): - total_post_pool_shares = (existing_shares + investor_shares) / (1 - target_option_pool) - option_pool_shares = target_option_pool * total_post_pool_shares - investor_ownership_final = investor_shares / total_post_pool_shares - return { - "total_post_pool_shares": total_post_pool_shares, - "option_pool_shares": option_pool_shares, - "investor_ownership_final": investor_ownership_final, - } diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py deleted file mode 100644 index 2906dad5..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py +++ /dev/null @@ -1,19 +0,0 @@ -def liquidation_preference(investment, liquidation_multiple=1, accrued_dividends=0): - return investment * liquidation_multiple + accrued_dividends - - -def nonparticipating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership): - return max(liquidation_preference_value, as_converted_ownership * exit_value) - - -def participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences): - if exit_value <= total_preferences: - return min(exit_value, liquidation_preference_value) - return liquidation_preference_value + as_converted_ownership * (exit_value - total_preferences) - - -def capped_participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences, cap_multiple, investment): - uncapped = participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences) - capped = min(uncapped, cap_multiple * investment) - converted = as_converted_ownership * exit_value - return max(capped, converted) diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py deleted file mode 100644 index 7e925a81..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/returns.py +++ /dev/null @@ -1,48 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def realized_return(price_start, price_end, dividend=0): - require_positive("price_start", price_start) - return (price_end - price_start + dividend) / price_start - - -def expected_return(returns, probabilities): - require_same_length("returns", returns, "probabilities", probabilities) - return sum(probability * return_value for return_value, probability in zip(returns, probabilities)) - - -def variance(returns, probabilities): - mean = expected_return(returns, probabilities) - return sum(probability * (return_value - mean) ** 2 for return_value, probability in zip(returns, probabilities)) - - -def standard_deviation(returns, probabilities): - return sqrt(variance(returns, probabilities)) - - -def historical_average_return(returns): - require_positive("number of returns", len(returns)) - return sum(returns) / len(returns) - - -def portfolio_expected_return(weights, expected_returns): - require_same_length("weights", weights, "expected_returns", expected_returns) - return sum(weight * expected_return_value for weight, expected_return_value in zip(weights, expected_returns)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py deleted file mode 100644 index bf065db7..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/risk.py +++ /dev/null @@ -1,41 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def portfolio_variance(weights, covariance_matrix): - rows = len(covariance_matrix) - require_same_length("weights", weights, "covariance_matrix rows", covariance_matrix) - for row in covariance_matrix: - require_same_length("weights", weights, "covariance_matrix row", row) - return sum(weights[i] * weights[j] * covariance_matrix[i][j] for i in range(rows) for j in range(rows)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) - - -def beta(asset_returns, market_returns): - market_variance = covariance(market_returns, market_returns) - require_positive("market variance", market_variance) - return covariance(asset_returns, market_returns) / market_variance - - -def estimate_beta_regression(asset_returns, market_returns, risk_free_rates): - require_same_length("asset_returns", asset_returns, "market_returns", market_returns) - require_same_length("asset_returns", asset_returns, "risk_free_rates", risk_free_rates) - excess_asset = [asset - risk_free for asset, risk_free in zip(asset_returns, risk_free_rates)] - excess_market = [market - risk_free for market, risk_free in zip(market_returns, risk_free_rates)] - return beta(excess_asset, excess_market) diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py deleted file mode 100644 index b8fcc474..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/safes.py +++ /dev/null @@ -1,15 +0,0 @@ -from validation import require_positive - - -def safe_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def safe_shares(investment_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return investment_amount / conversion_price - - -def post_money_safe_ownership(investment_amount, post_money_valuation_cap): - require_positive("post_money_valuation_cap", post_money_valuation_cap) - return investment_amount / post_money_valuation_cap diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py deleted file mode 100644 index 6d7850ba..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/time_value.py +++ /dev/null @@ -1,42 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth, require_same_length - - -def future_value(cash_flow, rate, periods): - return cash_flow * (1 + rate) ** periods - - -def present_value(cash_flow, rate, periods): - return cash_flow / (1 + rate) ** periods - - -def present_value_stream(cash_flows, rate): - return sum(present_value(cash_flow, rate, period) for period, cash_flow in enumerate(cash_flows, start=1)) - - -def present_value_with_spot_rates(cash_flows, spot_rates): - require_same_length("cash_flows", cash_flows, "spot_rates", spot_rates) - return sum(present_value(cash_flow, spot_rate, period) for period, (cash_flow, spot_rate) in enumerate(zip(cash_flows, spot_rates), start=1)) - - -def annuity_pv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * (1 - (1 + rate) ** (-periods)) / rate - - -def annuity_fv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * ((1 + rate) ** periods - 1) / rate - - -def perpetuity_pv(payment, rate): - require_positive("rate", rate) - return payment / rate - - -def growing_perpetuity_pv(next_payment, rate, growth_rate): - require_rate_greater_than_growth(rate, growth_rate) - return next_payment / (rate - growth_rate) diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py deleted file mode 100644 index a94535ec..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/validation.py +++ /dev/null @@ -1,33 +0,0 @@ -class FinanceValidationError(ValueError): - """Raised when a finance formula cannot be applied safely.""" - - -def require_positive(name, value): - if value <= 0: - raise FinanceValidationError(f"{name} must be positive.") - return value - - -def require_nonnegative(name, value): - if value < 0: - raise FinanceValidationError(f"{name} must be nonnegative.") - return value - - -def require_rate_greater_than_growth(rate, growth_rate, rate_name="rate"): - if rate <= growth_rate: - raise FinanceValidationError(f"{rate_name} must be greater than growth rate.") - - -def require_same_length(name_a, values_a, name_b, values_b): - if len(values_a) != len(values_b): - raise FinanceValidationError(f"{name_a} and {name_b} must have the same length.") - - -def warn_if(condition, message, warnings=None): - if not condition: - return warnings if warnings is not None else [] - if warnings is None: - warnings = [] - warnings.append(message) - return warnings diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py deleted file mode 100644 index 5c97d94a..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/valuation.py +++ /dev/null @@ -1,55 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth - - -def value_project_dcf(cash_flows, discount_rate, initial_investment): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def value_company_dcf(free_cash_flows, wacc, terminal_value): - return sum(fcf / (1 + wacc) ** period for period, fcf in enumerate(free_cash_flows, start=1)) + terminal_value / (1 + wacc) ** len(free_cash_flows) - - -def calculate_terminal_value_gordon(fcf_next, wacc, growth_rate): - require_rate_greater_than_growth(wacc, growth_rate, "wacc") - return fcf_next / (wacc - growth_rate) - - -def calculate_terminal_value_exit_multiple(metric, multiple): - return metric * multiple - - -def bridge_enterprise_to_equity_value(enterprise_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def calculate_price_per_share(equity_value, diluted_shares): - require_positive("diluted_shares", diluted_shares) - return equity_value / diluted_shares - - -def run_comparable_company_valuation(company_metric, comparable_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in comparable_multiples] - - -def run_precedent_transaction_valuation(company_metric, transaction_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in transaction_multiples] - - -def calculate_implied_multiple(value, metric): - require_positive("metric", metric) - return value / metric - - -def calculate_implied_value(metric, multiple): - return metric * multiple - - -def run_sensitivity_table(inputs, output_metric): - rows = [] - for case_name, case_inputs in inputs.items(): - rows.append({"case": case_name, "value": output_metric(**case_inputs)}) - return rows - - -def run_scenario_analysis(base_case, upside_case, downside_case): - return {"base": base_case, "upside": upside_case, "downside": downside_case} diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py deleted file mode 100644 index 77d56314..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/vc_method.py +++ /dev/null @@ -1,57 +0,0 @@ -from validation import require_positive - - -def burn_rate(monthly_expenses, monthly_cash_receipts=0): - return monthly_expenses - monthly_cash_receipts - - -def runway(cash_balance, monthly_net_burn): - require_positive("monthly_net_burn", monthly_net_burn) - return cash_balance / monthly_net_burn - - -def vc_target_multiple(required_return, holding_period, probability_success): - require_positive("probability_success", probability_success) - return (1 + required_return) ** holding_period / probability_success - - -def vc_present_value(successful_exit_value, probability_success, required_return, holding_period): - return successful_exit_value * probability_success / (1 + required_return) ** holding_period - - -def vc_total_valuation(successful_exit_value, retention, target_multiple): - require_positive("target_multiple", target_multiple) - return successful_exit_value * retention / target_multiple - - -def vc_partial_valuation(proposed_ownership, total_valuation): - return proposed_ownership * total_valuation - - -def vc_required_ownership(required_investment, total_valuation): - require_positive("total_valuation", total_valuation) - return required_investment / total_valuation - - -def post_money(investment, ownership): - require_positive("ownership", ownership) - return investment / ownership - - -def pre_money(post_money_value, investment): - return post_money_value - investment - - -def price_per_share(pre_money_value, fully_diluted_pre_money_shares): - require_positive("fully_diluted_pre_money_shares", fully_diluted_pre_money_shares) - return pre_money_value / fully_diluted_pre_money_shares - - -def new_shares(investment, price_per_share_value): - require_positive("price_per_share", price_per_share_value) - return investment / price_per_share_value - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares diff --git a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py b/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py deleted file mode 100644 index b147c830..00000000 --- a/plugins/productize-all/skills/productize-finance-modeling-kernel/finance-modeling-kernel/wacc.py +++ /dev/null @@ -1,9 +0,0 @@ -from validation import require_positive - - -def wacc(equity_value, debt_value, cost_of_equity, cost_of_debt, tax_rate): - total_value = equity_value + debt_value - require_positive("debt plus equity", total_value) - equity_weight = equity_value / total_value - debt_weight = debt_value / total_value - return equity_weight * cost_of_equity + debt_weight * (1 - tax_rate) * cost_of_debt diff --git a/plugins/productize-all/skills/productize-financial-markets-context/SKILL.md b/plugins/productize-all/skills/productize-financial-markets-context/SKILL.md deleted file mode 100644 index f0ea115f..00000000 --- a/plugins/productize-all/skills/productize-financial-markets-context/SKILL.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -name: productize-financial-markets-context -description: >- - Productize Finance context skill for market capitalization, market weights, index - concentration, listed-firm trends, public-company comparables, sector shifts, and CAPM - market-portfolio assumptions. ---- - - - -# Financial Markets Context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `financial-markets-context` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings - -## Purpose - -Market context skill. Use it to interpret public-market facts, index concentration, -listed-firm trends, market capitalization, comparable-company assumptions, sector -shifts, and market portfolio assumptions in CAPM. - -## Core Formulas - -- `Market Cap_i = Share Price_i * Shares Outstanding_i` -- `Weight_i = Market Cap_i / Total Market Cap` -- `Index Weight_i = Market Cap_i / sum(Market Cap of All Index Constituents)` -- `Global Weight_i = index weight * index share of country market * country share of world market` -- `Change in Listings = Listings_End - Listings_Start` -- `% Change = (End / Start - 1) * 100` -- `CAGR = (Ending Value / Beginning Value)^(1 / Years) - 1` - -## Interpretation Rules - -- Fewer listed firms does not necessarily mean a smaller equity market. -- Market capitalization can rise even if listings fall. -- This can happen because public firms become larger, smaller firms delist, and mergers concentrate value. -- Index concentration matters because the CAPM market portfolio is value-weighted. -- Public comparables may be biased if the target is much smaller, less mature, less profitable, or in a different sector. -- Sector composition changes over time, so historical index returns may reflect sector shifts, not only broad economic growth. - -## Required Validation - -- Warn if equal weighting is confused with value weighting. -- Warn if index concentration is ignored. -- Warn if public comparables are used for a startup without maturity adjustments. -- Warn if global market assumptions use only one domestic index. -- Warn if stale market weights are used. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Separate market fact, valuation implication, and comparability risk. diff --git a/plugins/productize-all/skills/productize-financial-markets-context/agents/openai.yaml b/plugins/productize-all/skills/productize-financial-markets-context/agents/openai.yaml deleted file mode 100644 index 0ae5d2ac..00000000 --- a/plugins/productize-all/skills/productize-financial-markets-context/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Financial Markets Context" - short_description: "Productize Finance context skill for market capitalization, market weights, index concentration, listed-firm trends,..." - brand_color: "#0369A1" - default_prompt: "Use $productize-financial-markets-context with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md b/plugins/productize-all/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md deleted file mode 100644 index 55ad6c4c..00000000 --- a/plugins/productize-all/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/SKILL.md +++ /dev/null @@ -1,422 +0,0 @@ ---- -name: productize-fragmented-user-research-synthesis-into-coherent-insights -description: >- - Fragmented user research synthesis into coherent insights. Use when the user needs a product - workflow for user research related to fragmented user research synthesis into coherent - insights. Trigger terms: user-research, synthesis, insights. ---- - - - -# Fragmented user research synthesis into coherent insights - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `fragmented-user-research-synthesis-into-coherent-insights` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Fragmented user research synthesis into coherent insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{RESEARCH_INPUTS}} -- {{PRODUCT_CONTEXT}} -- {{DESIGN_QUESTIONS}} -- {{CURRENT_ASSUMPTIONS}} -- {{BUSINESS_GOALS}} - - -GOAL -Produce a high-quality deliverable for: Fragmented user research synthesis into coherent insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Synthesize fragmented research inputs into coherent, evidence-based insights that inform design and product decisions. -- Use the provided inputs: -- `{{RESEARCH_INPUTS}}` -- `{{PRODUCT_CONTEXT}}` -- `{{DESIGN_QUESTIONS}}` -- `{{CURRENT_ASSUMPTIONS}}` -- `{{BUSINESS_GOALS}}` -- Perform synthesis rigorously: -- Inventory and assess source quality/coverage. -- Extract coded observations (quotes, behaviors, themes, segment/context metadata). -- Identify cross-source patterns and contradictions. -- Assign confidence levels with explicit rationale. -- Map insights to JTBD and user-needs hierarchy. -- Link insights directly to design questions and actionable recommendations. -- Identify research gaps, unresolved assumptions, and prioritized follow-up research. -- Keep evidence traceable, avoid over-generalization, and state assumptions/uncertainties explicitly. - -FORMAT -Return exactly this structure: - - - -**Data Sources Summary:** -- User interviews: [X participants] covering [topics, user segments, dates] -- Support tickets: [Y tickets] from [date range] about [primary themes] -- NPS feedback: [Z responses] with [average score] discussing [key topics] -- Usage analytics: [data range, key metrics, user actions analyzed] -- Feature requests: [count] requests across [platforms/sources] -- Usability tests: [sessions count] testing [specific flows or features] -- Survey data: [respondents count] on [topics covered] -- Anecdotal feedback: [source count] from [stakeholders, channels] -- Session recordings: [count] sessions showing [behaviors] -- Other sources: [specify any additional data] - -**Data Quality Assessment:** -- Time range: [how recent is this data?] -- User segment coverage: [which personas/segments are represented?] -- Sample size adequacy: [sufficient for confidence in findings?] -- Potential bias: [what perspectives might be over/under-represented?] -- Data completeness: [what's missing or sparse?] - - - - -**Insight Statement:** -[One clear, specific sentence stating what you learned about users] - -**Evidence:** -- User interviews: "[verbatim quote]" (Participant X, [segment]) -- Support tickets: [Y tickets] report "[specific issue]" with keywords: [terms] -- NPS feedback: "[example comment]" (common theme in Z% of detractor responses) -- Analytics data: [X% of users] exhibit [specific behavior], [frequency/context] -- Additional evidence: [any other supporting data points] - -**Confidence Level:** High / Medium / Low -**Rationale for Confidence:** [Why you assigned this confidence level] - -**User Segments Affected:** -- [Segment 1]: [how this manifests for them] -- [Segment 2]: [how this manifests for them] - -**Jobs-to-be-Done Connection:** -[Which job is this insight related to? How does it help or hinder job completion?] - -**Design Implications:** -- Consider: [specific design approach this suggests] -- Avoid: [what this insight argues against] -- Prioritize: [which aspect of the experience to focus on] -- Measure: [how to validate design addressed this insight] - -**Related Patterns:** -[Which other insights connect to this? How do they reinforce or complicate each other?] - -**Business Impact:** -[How does addressing this insight connect to business goals or metrics?] - - - -[Repeat the full structure for 5-10 key insights, maintaining consistent depth and evidence rigor] - - - -[Continue for all major insights...] - - - - -**Conflict 1:** -- Signal A: [what one source or segment indicates] -- Signal B: [what contradicts this] -- Possible explanations: - * [Explanation 1: e.g., different user segments with different needs] - * [Explanation 2: e.g., stated preference vs. actual behavior] - * [Explanation 3: e.g., context-dependent variation] -- Recommended resolution: [What research or analysis would clarify this?] -- Design strategy given conflict: [How to proceed despite uncertainty?] - -**Conflict 2:** -[Repeat structure for each major contradiction in the data] - -**Synthesis:** -[What do these conflicts reveal about user diversity, product complexity, or research gaps?] - - - -**Question 1:** [Restate the first design question] -- **Answer based on research:** [What the data tells you] -- **Supporting insights:** [Which insights from above inform this answer] -- **Confidence level:** High / Medium / Low -- **Caveats and limitations:** [What qualifies or nuances this answer] -- **What we still don't know:** [Gaps specific to this question] -- **Recommended action:** [What to design/test/research next] - -**Question 2:** [Restate the second design question] -[Repeat structure for each design question provided] - -**New Questions Surfaced:** -[Design questions that emerged from the research but weren't originally asked] - - - - -**Must-Have Needs (Strong Evidence, High Impact):** -1. [Need 1]: [description] - - Evidence: [cross-source validation] - - If unmet: [severe user/business consequence] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat structure for 3-5 critical needs] - - - -**Should-Have Needs (Moderate Evidence, Meaningful Impact):** -1. [Need 1]: [description] - - Evidence: [validation from 1-2 strong sources] - - If unmet: [moderate user friction or business impact] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat for 5-8 important needs] - - - -**Nice-to-Have Needs (Weak Signal, Low/Uncertain Impact):** -1. [Need 1]: [description] - - Evidence: [limited mentions or single source] - - Potential value: [why this might matter despite weak signal] - - Validation needed: [how to test if this is actually important] - -2. [Need 2]: [description] - [Repeat for 3-5 nice-to-have needs] - - - -**Segment-Specific Needs:** -- [Segment A]: [unique needs not shared by other segments] -- [Segment B]: [unique needs not shared by other segments] -- [Universal needs]: [needs expressed across all segments] - - - - -**Current Workflows and Workarounds:** -[Describe how users actually accomplish tasks today, including inefficient or creative workarounds that reveal unmet needs] - -**Decision-Making Patterns:** -[How users make choices within the product, what information they seek, what causes hesitation or confidence] - -**Pain Point Triggers:** -[Specific circumstances, contexts, or actions that consistently lead to user frustration] - -**Success Patterns:** -[When and how users successfully achieve their goals, what enables their success] - -**Usage Context and Frequency:** -[When, where, why, and how often users engage with the product or specific features] - -**Adoption and Learning Patterns:** -[How users onboard themselves, what helps or hinders learning, common confusion points] - -**Abandonment and Recovery Patterns:** -[What causes users to give up, what brings them back, how they recover from errors] - -**Cross-Tool Workflows:** -[How users combine your product with other tools, what gaps force tool-switching] - - - -**Primary Functional Jobs:** -1. [Job]: When [situation], I want to [motivation], so I can [expected outcome] - - Evidence: [how research revealed this job] - - Current obstacles: [what prevents job completion] - - Success criteria: [how users define successful job completion] - -2. [Job]: [Repeat structure for 3-5 primary jobs] - -**Emotional Jobs:** -- [Feel]: [emotion users want to feel, e.g., "feel confident in my decisions"] -- [Avoid]: [emotion users want to avoid, e.g., "avoid feeling overwhelmed"] -- Evidence: [quotes, observations, sentiment indicators] - -**Social Jobs:** -- [Perception]: [how users want to be seen, e.g., "be perceived as data-driven"] -- [Context]: [social situations where product use matters] -- Evidence: [research indicators of social motivations] - -**Related Jobs in the Consumption Chain:** -- Before main job: [how users discover, evaluate, and choose the product] -- After main job: [how users share, report, or build on outcomes] -- Maintenance jobs: [ongoing tasks to keep getting value] - - - - -**Critical Unknowns (Blocking Design Decisions):** -1. [Question]: [why this matters for design] -2. [Question]: [why this matters for design] -3. [Question]: [why this matters for design] - -**Important Unknowns (Would Significantly Inform Design):** -1. [Question]: [how this would help] -2. [Question]: [how this would help] - -**Curiosities (Interesting But Not Urgent):** -1. [Question]: [potential value] -2. [Question]: [potential value] - - - -**Research Activity 1:** -- **Method:** [interviews / usability testing / survey / analytics deep-dive / diary study / etc.] -- **Target participants:** [which user segments, how many, recruitment criteria] -- **Key questions to answer:** [specific questions this research would resolve] -- **Expected outcomes:** [what you'll learn and how it informs design] -- **Effort estimate:** [time and resources required] -- **Priority:** High / Medium / Low - [rationale] - -**Research Activity 2:** -[Repeat structure for 3-5 recommended research activities, prioritized by impact and urgency] - - - -**Design Assumptions:** -1. [Assumption about user behavior or preferences]: Currently [validated / unvalidated / contradicted] by research -2. [Assumption about priorities or needs]: Currently [status] -3. [Assumption about technical or business constraints]: Currently [status] - -**Team Assumptions:** -[Assumptions stakeholders or team members hold that aren't supported by dataโ€”list with gentle evidence-based reframing] - -**Testing Strategy:** -[How to quickly validate or invalidate the most critical assumptions through lightweight tests] - - - - -**Priority 1 Recommendations (Supported by High-Confidence Insights):** -1. [Specific design action]: [rationale tied to insight X, Y, Z] - - Expected impact: [user and business outcomes] - - Success metrics: [how to measure if this worked] - -2. [Specific design action]: [rationale tied to insights] - [Repeat for 3-5 top-priority recommendations] - -**Priority 2 Recommendations (Supported by Medium-Confidence Insights):** -1. [Specific design action]: [rationale] - [Repeat for 5-7 secondary recommendations] - -**Quick Wins (Low Effort, Clear User Value):** -1. [Specific design action]: [why this is easy and valuable] - [Repeat for 3-5 quick wins] - -**Strategic Bets (Lower Confidence, High Potential):** -1. [Specific design action]: [why worth exploring despite uncertainty] - - Validation approach: [how to test before full commitment] - [Repeat for 2-3 strategic bets] - -**Do Not Pursue:** -[Features, changes, or directions that research argues against, with rationale] - - - -**Executive Summary** - -**What We Learned:** -[2-3 sentences capturing the most important insights from the research] - -**User Needs Priority:** -Users critically need [top need], strongly want [second need], and would appreciate [third need]. The evidence is strongest for [insight area] and weakest for [insight area requiring validation]. - -**Key Behavioral Patterns:** -[1-2 sentences on how users actually behave vs. what we might have assumed] - -**Design Implications:** -The research strongly supports [recommended direction 1] and [recommended direction 2], while arguing against [current assumption or planned direction]. We should prioritize [specific user segment or job-to-be-done] because [evidence-based rationale]. - -**Critical Unknowns:** -We still need to understand [key gap 1] and [key gap 2] through [recommended research method]. - -**Recommended Next Steps:** -1. [Immediate action based on high-confidence insights] -2. [Design exploration for medium-confidence opportunities] -3. [Targeted research to fill critical gaps] - -**Business Impact:** -Addressing these insights is expected to improve [business metric] by [directional estimate] because [user behavior change expected]. - -[Total: 250-350 words] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Insights are not supported by cross-source evidence or confidence rationale. -- Contradictions are ignored or not addressed with a resolution approach. -- Recommendations are not prioritized or not linked to synthesized insights/business goals. -- Research gaps and assumption validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/agents/openai.yaml b/plugins/productize-all/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/agents/openai.yaml deleted file mode 100644 index 9d0bda95..00000000 --- a/plugins/productize-all/skills/productize-fragmented-user-research-synthesis-into-coherent-insights/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Fragmented user research synthesis into coherent insights" - short_description: "Fragmented user research synthesis into coherent insights. Use when the user needs a product workflow for user..." - brand_color: "#0D9488" - default_prompt: "Use $productize-fragmented-user-research-synthesis-into-coherent-insights with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md b/plugins/productize-all/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md deleted file mode 100644 index fc5dbcfc..00000000 --- a/plugins/productize-all/skills/productize-framework-application-to-product-challenges-from-user-input/SKILL.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -name: productize-framework-application-to-product-challenges-from-user-input -description: >- - Framework application to product challenges from user input. Use when the user needs a - product workflow for product strategy related to framework application to product challenges - from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching. ---- - - - -# Framework application to product challenges from user input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `framework-application-to-product-challenges-from-user-input` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Framework application to product challenges from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRAMEWORK}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Framework application to product challenges from user input. -Success metric: -- Asks targeted questions when key context is missing. -- Applies the provided framework precisely to the userโ€™s situation. -- Produces actionable advice and a clear recommendation when sufficient context exists. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{FRAMEWORK}}` and `{{USER_INPUT}}`; if key context is missing, ask targeted questions first. -- Do not summarize the framework back to the user. -- When asking for more information, use `` tags only. -- When providing guidance, use `` tags only. -- When providing a final recommendation, use `` tags only. -- Keep advice specific and grounded in the userโ€™s context; avoid generic PM guidance. - -FORMAT -Return exactly this structure: - - -[Targeted questions needed to apply the framework] - - - -[Framework-applied guidance once sufficient context exists] - - - -[Final recommendation when enough context exists] - - -FAILURE -- Required tags are missing or malformed. -- Output includes framework summary instead of application. -- Advice is generic or not tied to the user input. -- Recommendation is provided without sufficient context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-framework-application-to-product-challenges-from-user-input/agents/openai.yaml b/plugins/productize-all/skills/productize-framework-application-to-product-challenges-from-user-input/agents/openai.yaml deleted file mode 100644 index 96e093f4..00000000 --- a/plugins/productize-all/skills/productize-framework-application-to-product-challenges-from-user-input/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Framework application to product challenges from user input" - short_description: "Framework application to product challenges from user input. Use when the user needs a product workflow for product..." - brand_color: "#059669" - default_prompt: "Use $productize-framework-application-to-product-challenges-from-user-input with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-frontend-design/SKILL.md b/plugins/productize-all/skills/productize-frontend-design/SKILL.md deleted file mode 100644 index b21a1c23..00000000 --- a/plugins/productize-all/skills/productize-frontend-design/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-frontend-design -description: >- - Design implementation-ready frontend solutions with UX intent, component structure, - responsive behavior, accessibility, and handoff criteria. ---- - - - -# Frontend Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `frontend-design` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to design frontend behavior and UI structure before or alongside implementation. - -## The Process - -### Step 1: Define UX objective - -Capture: -- user goal -- primary user flow -- success state and failure states - -### Step 2: Specify UI architecture - -Define: -- screen/layout structure -- component hierarchy -- state model (loading, empty, error, success) - -### Step 3: Specify design system decisions - -Set: -- typography and spacing rules -- color/contrast constraints -- interaction patterns - -### Step 4: Specify responsive and accessibility requirements - -Include: -- breakpoints and behavior changes -- keyboard navigation expectations -- ARIA/semantic requirements -- contrast and focus visibility requirements - -### Step 5: Define implementation handoff - -Provide: -- component list and props/state contract -- acceptance criteria -- verification checklist - -## Output Format - -```markdown -# [Feature Name] Frontend Design Spec - -## UX Objective -- User goal: -- Primary flow: -- Success/failure states: - -## UI Architecture -- Layout: -- Component hierarchy: -- State model: - -## Responsive Behavior -- Desktop: -- Tablet: -- Mobile: - -## Accessibility Requirements -- Keyboard: -- Semantics/ARIA: -- Contrast/focus: - -## Handoff -- Components to implement: -- Acceptance criteria: -- Verification checklist: -``` - -## Quality Bar - -- Design decisions must map to user goals -- Accessibility section is mandatory -- Handoff must be implementable without extra interpretation - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/plugins/productize-all/skills/productize-frontend-design/agents/openai.yaml b/plugins/productize-all/skills/productize-frontend-design/agents/openai.yaml deleted file mode 100644 index b012c9c3..00000000 --- a/plugins/productize-all/skills/productize-frontend-design/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Frontend Design" - short_description: "Design implementation-ready frontend solutions with UX intent, component structure, responsive behavior,..." - brand_color: "#DB2777" - default_prompt: "Use $productize-frontend-design with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md b/plugins/productize-all/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md deleted file mode 100644 index 62097374..00000000 --- a/plugins/productize-all/skills/productize-future-product-opportunities-from-market-inflection-points/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: productize-future-product-opportunities-from-market-inflection-points -description: >- - Future product opportunities from market inflection points. Use when the user needs a - product workflow for product strategy related to future product opportunities from market - inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, - trends, product-vision. ---- - - - -# Future product opportunities from market inflection points - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `future-product-opportunities-from-market-inflection-points` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Future product opportunities from market inflection points**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_YEAR}} -- {{RESEARCH_TIMEFRAME}} - - -GOAL -Produce a high-quality deliverable for: Future product opportunities from market inflection points. -Success metric: -- Identifies concrete regulatory, technological, and belief inflection points within the stated timeframe. -- Connects converging trends to 3โ€“5 plausible future opportunities. -- Provides actionable challenges and timelines for each opportunity. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_YEAR}}` and `{{RESEARCH_TIMEFRAME}}`; if context is missing, state assumptions explicitly. -- List 3โ€“5 items per inflection category (regulatory, technological, belief). -- Provide 3โ€“5 converging trend sets that explicitly combine at least two categories. -- Provide 3โ€“5 future opportunities with concept, enabling trends, challenges, and timeline. -- Keep opportunities plausible within the specified research timeframe. - -FORMAT -Return exactly this structure: - - -1. Inflection Points: - a. Regulatory: - - [List 3โ€“5 significant regulatory changes] - b. Technological: - - [List 3โ€“5 important technological advancements] - c. Belief: - - [List 3โ€“5 notable shifts in societal attitudes or behaviors] - -2. Converging Trends: - - [Describe 3โ€“5 sets of converging trends, explaining how they intersect] - -3. Future Opportunities: - [For each opportunity (aim for 3โ€“5), include:] - a. Concept: [Brief description] - b. Enabling Trends: [List the key inflection points or converging trends] - c. Challenges: [Potential barriers or difficulties] - d. Timeline: [Estimated timeframe for realization] - -4. Conclusion: - [Summarize the most promising areas for innovation based on your analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any inflection category has fewer than 3 or more than 5 items. -- Converging trends do not combine multiple categories. -- Opportunities are missing required fields or outside the specified timeframe. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-future-product-opportunities-from-market-inflection-points/agents/openai.yaml b/plugins/productize-all/skills/productize-future-product-opportunities-from-market-inflection-points/agents/openai.yaml deleted file mode 100644 index 9dcfc742..00000000 --- a/plugins/productize-all/skills/productize-future-product-opportunities-from-market-inflection-points/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Future product opportunities from market inflection points" - short_description: "Future product opportunities from market inflection points. Use when the user needs a product workflow for product..." - brand_color: "#059669" - default_prompt: "Use $productize-future-product-opportunities-from-market-inflection-points with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-group-decision-making-quality-review/SKILL.md b/plugins/productize-all/skills/productize-group-decision-making-quality-review/SKILL.md deleted file mode 100644 index cb5bacdc..00000000 --- a/plugins/productize-all/skills/productize-group-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: productize-group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, or - operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group - decides. ---- - - - -# Group Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `group-decision-making-quality-review` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/plugins/productize-all/skills/productize-group-decision-making-quality-review/agents/openai.yaml b/plugins/productize-all/skills/productize-group-decision-making-quality-review/agents/openai.yaml deleted file mode 100644 index 33073d0e..00000000 --- a/plugins/productize-all/skills/productize-group-decision-making-quality-review/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Group Decision Making Quality Review" - short_description: "Review and design a group decision-making process for product, strategy, roadmap, launch, or operating decisions...." - brand_color: "#7C2D12" - default_prompt: "Use $productize-group-decision-making-quality-review with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-grow/SKILL.md b/plugins/productize-all/skills/productize-grow/SKILL.md deleted file mode 100644 index c1b5d4fb..00000000 --- a/plugins/productize-all/skills/productize-grow/SKILL.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: productize-grow -description: >- - Productize grow playbook for stable products with activation evidence. Use when the product - has a working core and the team needs growth diagnosis, growth loops, GTM choices, - onboarding, retention, pricing, lifecycle triggers, and experiment cadence. ---- - - - -# Productize Grow - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `grow` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition - -Use this playbook when the core product is stable enough to grow. Grow is not the -place to invent the product; use `$0-1` for new bets and `$operate` for continuous -production health. - -## Cadence - -- Trigger: stable activation, repeat usage, clear ICP, or a growth bottleneck. -- Rhythm: weekly experiment planning and readout, with metric reviews before changing - channels, onboarding, pricing, or lifecycle triggers. -- Closure: target hit, target abandoned, strategy pivot, or evidence that the product - needs a new `$0-1` loop. - -## Route Internally - -- Product-market fit and bottlenecks: `$product-market-fit-cycle`, `$aarrr-growth-diagnostics`, `$metrics-review` -- Loops and experiments: `$growth-loops`, `$plg-growth-playbook`, `$growth-project-generation-with-pioneer-migrator-settler`, `$robust-experiment-design-from-goals-and-systems` -- GTM and lifecycle: `$gtm-motions`, `$gtm-strategy`, `$onboarding-flow-optimization-from-product-data-to-user-success` -- Retention and monetization: `$churn-reduction-from-customer-data-and-exit-survey-analysis`, `$pricing-strategy`, `$monetization-strategy` -- Gates: `$product-review`, `$qa`, `$comms-review`, `$docs`, `$release` - -## Required Output - -Return: - -1. **Growth State**: ICP, activation evidence, retention signal, bottleneck, and metric caveats. -2. **Growth Thesis**: target, growth loop, channel or lifecycle trigger, and why it fits the current evidence. -3. **Experiment Cadence**: tests, owners, sample size or evidence threshold, and stop/pivot rules. -4. **Gate Calls**: product, QA, docs, release, or comms gates needed before launch. -5. **Closure Condition**: target hit, pivot, pause, or new `$0-1` bet. diff --git a/plugins/productize-all/skills/productize-grow/agents/openai.yaml b/plugins/productize-all/skills/productize-grow/agents/openai.yaml deleted file mode 100644 index c3178677..00000000 --- a/plugins/productize-all/skills/productize-grow/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Productize Grow" - short_description: "Productize grow playbook for stable products with activation evidence. Use when the product has a working core and..." - brand_color: "#C2410C" - default_prompt: "Use $productize-grow with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-growth-loops/SKILL.md b/plugins/productize-all/skills/productize-growth-loops/SKILL.md deleted file mode 100644 index 4f439fbc..00000000 --- a/plugins/productize-all/skills/productize-growth-loops/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: productize-growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- - - - -# Growth Loops - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-loops` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/plugins/productize-all/skills/productize-growth-loops/agents/openai.yaml b/plugins/productize-all/skills/productize-growth-loops/agents/openai.yaml deleted file mode 100644 index f76d126f..00000000 --- a/plugins/productize-all/skills/productize-growth-loops/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Growth Loops" - short_description: "Growth Loops. Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or..." - brand_color: "#C2410C" - default_prompt: "Use $productize-growth-loops with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md b/plugins/productize-all/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md deleted file mode 100644 index 4c847103..00000000 --- a/plugins/productize-all/skills/productize-growth-project-generation-with-pioneer-migrator-settler/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: productize-growth-project-generation-with-pioneer-migrator-settler -description: >- - Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a - product workflow for product strategy related to growth project generation with - pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, - portfolio. ---- - - - -# Growth project generation with Pioneer-Migrator-Settler framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-project-generation-with-pioneer-migrator-settler` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Growth project generation with Pioneer-Migrator-Settler framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY}} - - -GOAL -Produce a high-quality deliverable for: Growth project generation with Pioneer-Migrator-Settler framework. -Success metric: -- Produces 12 distinct growth projects categorized into Pioneer/Migrator/Settler. -- Ensures balanced portfolio logic and a brief plan to drive growth. -- Keeps ideas concrete, differentiated, and aligned to the company context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY}}`; if details are missing, state assumptions explicitly. -- Generate exactly 12 distinct growth projects: - - 3 creative, - - 3 weird, - - 3 compelling, - - 3 novel and unexpected. -- Each idea must be tagged as one of: Pioneer, Migrator, Settler. -- Keep ideas concrete and specific to the companyโ€™s context. -- Provide a brief analysis of portfolio balance and strategic impact. -- Provide a short growth plan for how to build new market space and profitable growth. - -FORMAT -Return exactly this structure: - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - - -[Brief analysis of mix and impact, with portfolio balance insights] - - - -[Brief plan for creating new market space and profitable growth] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer or more than 12 ideas are provided. -- Any idea is missing a Pioneer/Migrator/Settler category. -- Ideas are generic or not grounded in the company context. -- Analysis or growth plan is missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-growth-project-generation-with-pioneer-migrator-settler/agents/openai.yaml b/plugins/productize-all/skills/productize-growth-project-generation-with-pioneer-migrator-settler/agents/openai.yaml deleted file mode 100644 index 2e3f56b9..00000000 --- a/plugins/productize-all/skills/productize-growth-project-generation-with-pioneer-migrator-settler/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Growth project generation with Pioneer-Migrator-Settler framework" - short_description: "Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a product workflow for..." - brand_color: "#C2410C" - default_prompt: "Use $productize-growth-project-generation-with-pioneer-migrator-settler with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md b/plugins/productize-all/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md deleted file mode 100644 index 99d9f24c..00000000 --- a/plugins/productize-all/skills/productize-growth-strategy-synthesis-from-user-inputs/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: productize-growth-strategy-synthesis-from-user-inputs -description: >- - Growth strategy synthesis from user inputs. Use when the user needs a product workflow for - product strategy related to growth strategy synthesis from user inputs. Trigger terms: - growth, strategy, experimentation, metrics, distribution. ---- - - - -# Growth strategy synthesis from user inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-strategy-synthesis-from-user-inputs` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth strategy brief with bets, loops, experiments, and metrics - -Use this skill to run the Productize prompt contract for **Growth strategy synthesis from user inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUTS}} - - -GOAL -Produce a high-quality deliverable for: Growth strategy synthesis from user inputs. -Success metric: -- Produces a complete growth strategy across model, constraints, horizon, method, principle, and catalyst. -- Grounds all recommendations in the provided user inputs. -- Outputs actionable, testable recommendations and a concise summary. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUTS}}`; if critical data is missing, state assumptions explicitly. -- Address each required section: model, constraint, horizon, method, principle, catalyst, summary. -- Keep recommendations actionable and testable; avoid generic advice. -- If quantitative data is present, reference it; if not, use qualitative reasoning and label assumptions. - -FORMAT -Return exactly this structure: - - - -[Provide a detailed description of the growth model] - - - -[Identify and explain the main growth constraints] - - - -[Analyze the growth horizon and potential limitations] - - - -[Propose specific methods to address constraints and extend the growth horizon] - - - -[Develop a guiding principle for aligning the organization] - - - -[Identify and explain any growth catalysts] - - - -[Provide a brief summary of the overall growth strategy] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Recommendations are not tied to the provided inputs. -- Growth method lacks actionable steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-growth-strategy-synthesis-from-user-inputs/agents/openai.yaml b/plugins/productize-all/skills/productize-growth-strategy-synthesis-from-user-inputs/agents/openai.yaml deleted file mode 100644 index 00b248c2..00000000 --- a/plugins/productize-all/skills/productize-growth-strategy-synthesis-from-user-inputs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Growth strategy synthesis from user inputs" - short_description: "Growth strategy synthesis from user inputs. Use when the user needs a product workflow for product strategy related..." - brand_color: "#C2410C" - default_prompt: "Use $productize-growth-strategy-synthesis-from-user-inputs with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-gtm-motions/SKILL.md b/plugins/productize-all/skills/productize-gtm-motions/SKILL.md deleted file mode 100644 index a9650ffb..00000000 --- a/plugins/productize-all/skills/productize-gtm-motions/SKILL.md +++ /dev/null @@ -1,236 +0,0 @@ ---- -name: productize-gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, - partner, ABM, or hybrid go-to-market motions. ---- - - - -# GTM Motions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-motions` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/plugins/productize-all/skills/productize-gtm-motions/agents/openai.yaml b/plugins/productize-all/skills/productize-gtm-motions/agents/openai.yaml deleted file mode 100644 index ed4912ea..00000000 --- a/plugins/productize-all/skills/productize-gtm-motions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "GTM Motions" - short_description: "GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid..." - brand_color: "#C2410C" - default_prompt: "Use $productize-gtm-motions with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-gtm-strategy/SKILL.md b/plugins/productize-all/skills/productize-gtm-strategy/SKILL.md deleted file mode 100644 index 22360c0b..00000000 --- a/plugins/productize-all/skills/productize-gtm-strategy/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: productize-gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- - - - -# GTM Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/plugins/productize-all/skills/productize-gtm-strategy/agents/openai.yaml b/plugins/productize-all/skills/productize-gtm-strategy/agents/openai.yaml deleted file mode 100644 index 5453696d..00000000 --- a/plugins/productize-all/skills/productize-gtm-strategy/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "GTM Strategy" - short_description: "GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market entry, launch, or..." - brand_color: "#C2410C" - default_prompt: "Use $productize-gtm-strategy with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md b/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md deleted file mode 100644 index 5d62c3c7..00000000 --- a/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- - - - -# Ideal Customer Profile (ICP) representative for X product - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideal-customer-profile-icp-representative-for-x-product` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/agents/openai.yaml b/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/agents/openai.yaml deleted file mode 100644 index fb4fe712..00000000 --- a/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Ideal Customer Profile (ICP) representative for X product" - short_description: "Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product workflow for user..." - brand_color: "#0D9488" - default_prompt: "Use $productize-ideal-customer-profile-icp-representative-for-x-product with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md b/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md deleted file mode 100644 index 3be9171c..00000000 --- a/plugins/productize-all/skills/productize-ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md +++ /dev/null @@ -1,171 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make ICP outputs sharper on demographics, behaviors, JTBD, PMF evidence, and best-customer patterns. - -## Routing Signals - -- ideal customer profile -- icp -- pmf survey -- best customers - -## pm-go-to-market/skills/ideal-customer-profile/SKILL.md - -## Overview -Identify your Ideal Customer Profile (ICP) from research and survey data. This skill synthesizes customer research to define the customer most likely to find value, retain, and expand with your product. - -## When to Use -- Defining ICP from product-market fit survey data -- Targeting high-value customer segments -- Analyzing customer success and expansion patterns -- Prioritizing sales and marketing efforts -- Evaluating new customer opportunities for fit -- Refining target market definition - -## ICP Framework Components - -### Demographics -Who are they from a firmographic and personal perspective? -- Company size (employees, revenue) -- Industry or vertical -- Geographic location -- Job title and department -- Years of experience in role -- Education and background -- Organizational structure and reporting - -### Behaviors -How do they work and make decisions? -- How they discover and evaluate solutions -- Buying process and decision-making timeline -- Technical literacy and product adoption speed -- Collaboration style (solo decision vs committee) -- Change management and adoption style -- Tool switching frequency -- Community involvement and peer influence - -### Jobs to Be Done (JTBD) -What are they trying to accomplish? -- Primary job/goal they're trying to achieve -- Secondary jobs that support the primary job -- Emotional jobs (how they want to feel) -- Social jobs (status and perception) -- Jobs they avoid or want to eliminate -- Frequency and importance of each job -- Success metrics for completing job - -### Needs and Pain Points -What problems does your product solve? -- Specific pain points they experience -- Current workarounds and limitations -- Impact on productivity or outcomes -- Cost or time burden of the problem -- Emotional frustration levels -- Barriers to solving the problem -- Available budget to solve -- Competing priorities - -## How It Works - -### Step 1: Gather Customer Data -Collect research about actual and potential customers: -- Product-market fit survey responses -- Customer interview transcripts -- Trial or freemium user behavior data -- Customer feedback and support tickets -- Churn analysis and customer lifecycle data -- Win/loss analysis from sales -- Competitor customer analysis - -### Step 2: Segment by Value -Identify customer cohorts and their value: -- Highest LTV (lifetime value) customers -- Fastest time-to-value customers -- Lowest churn rate customers -- Highest expansion/upsell customers -- Most enthusiastic/engaged customers -- Best reference/case study potential -- Most aligned with product vision - -### Step 3: Profile Demographics -Extract firmographic patterns: -- Common company sizes (employee count, revenue) -- Industry verticals and sub-verticals -- Geographic concentrations -- Typical department and reporting structure -- Budget holders and budget available -- Company stage (startup, growth, enterprise) -- Company culture indicators - -### Step 4: Identify Behaviors -Map decision-making and adoption patterns: -- How they discovered your product (channel) -- Evaluation process and timeline -- Key stakeholders in decision -- Obstacles during sales process -- Product adoption speed and breadth -- Team involvement in onboarding -- Frequency of feature usage -- Support and service needs - -### Step 5: Define JTBD -Articulate what they're trying to accomplish: -- Primary job/goal (functional job) -- Emotional dimensions (how they want to feel) -- Social dimensions (team and stakeholder impact) -- Success metrics (how they measure success) -- Context and constraints (when, where, with whom) -- Competing jobs and priorities -- Importance ranking of various jobs - -### Step 6: Document Pain Points and Needs -Synthesize specific problem areas: -- Before state (current situation and frustrations) -- Desired after state (ideal future state) -- Gap size and impact quantification -- Emotional dimensions of the problem -- Resource constraints preventing solutions -- Skepticism or hesitations -- Success criteria for solution - -## Input Format -Use $ARGUMENTS to pass: -- Research data (surveys, interviews, transcripts) -- Customer success/metrics data -- Product usage analytics -- Sales activity and win/loss data -- Existing customer database -- Competitive intelligence - -## Output -A comprehensive ICP definition including: -- Firmographic profile (company size, industry, location) -- Behavioral profile (buying patterns, adoption style) -- Complete JTBD mapping (functional, emotional, social jobs) -- Top 5-7 pain points and specific needs -- Quantified impact metrics (cost of problem, value of solution) -- Decision-making process and key stakeholders -- Typical customer journey and timeline -- Go-to-market implications and messaging -- Disqualification criteria (who is NOT a good fit) -- High-value segment within ICP (ideal-of-the-ideal) - -## Framework -Based on Jobs to Be Done theory by Clayton Christensen and customer profiling methodology. Combines behavioral data with motivational insights to define actionable customer profiles. - -## Tips -- Use quantitative and qualitative data together -- Interview 10+ high-value customers for pattern identification -- Look for non-obvious demographic patterns (outliers can be high-value) -- Define both ideal ICP and acceptable secondary segments -- Revisit ICP quarterly as you gather more customer data -- Use ICP to evaluate all new sales opportunities -- Share ICP across entire organization (marketing, sales, product) -- Remember: ICP should drive focus, not exclude all others - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/plugins/productize-all/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md b/plugins/productize-all/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md deleted file mode 100644 index 34c8b07f..00000000 --- a/plugins/productize-all/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem -description: >- - Ideas for affordances and signifiers based on a design problem. Use when the user needs a - product workflow for design & prototyping related to ideas for affordances and signifiers - based on a design problem. Trigger terms: ux, interaction-design, affordances, usability. ---- - - - -# Ideas for affordances and signifiers based on a design problem - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideas-for-affordances-and-signifiers-based-on-a-design-problem` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Ideas for affordances and signifiers based on a design problem**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_CHALLENGE}} - - -GOAL -Produce a high-quality deliverable for: Ideas for affordances and signifiers based on a design problem. -Success metric: -- Identifies key user interactions in the design challenge before proposing ideas. -- Produces at least 5 concrete ideas each for affordances, perceived affordances, and signifiers. -- Each idea includes a brief explanation tied to the challenge and UX impact. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DESIGN_CHALLENGE}}`; if context is incomplete, state assumptions explicitly. -- Start with a brief interaction analysis identifying main user functions/tasks. -- Generate at least 5 ideas in each category: affordances, perceived affordances, signifiers. -- For every idea, include a short explanation linking: - - the specific challenge friction/opportunity, - - how the idea guides user action or perception, - - expected UX improvement. -- Keep ideas practical, non-generic, and directly relevant to the described product context. - -FORMAT -Return exactly this structure: - - - -[Main user interactions/functions required by the challenge] - - - -1. [Affordance idea] - [Brief explanation] -2. [Affordance idea] - [Brief explanation] -3. [Affordance idea] - [Brief explanation] -4. [Affordance idea] - [Brief explanation] -5. [Affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Perceived affordance idea] - [Brief explanation] -2. [Perceived affordance idea] - [Brief explanation] -3. [Perceived affordance idea] - [Brief explanation] -4. [Perceived affordance idea] - [Brief explanation] -5. [Perceived affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Signifier idea] - [Brief explanation] -2. [Signifier idea] - [Brief explanation] -3. [Signifier idea] - [Brief explanation] -4. [Signifier idea] - [Brief explanation] -5. [Signifier idea] - [Brief explanation] -[Optional additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 5 ideas in any required category. -- Explanations are missing for one or more ideas. -- No interaction analysis is provided before idea lists. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/agents/openai.yaml b/plugins/productize-all/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/agents/openai.yaml deleted file mode 100644 index c0302eaf..00000000 --- a/plugins/productize-all/skills/productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Ideas for affordances and signifiers based on a design problem" - short_description: "Ideas for affordances and signifiers based on a design problem. Use when the user needs a product workflow for..." - brand_color: "#DB2777" - default_prompt: "Use $productize-ideas-for-affordances-and-signifiers-based-on-a-design-problem with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-implementation-notes/SKILL.md b/plugins/productize-all/skills/productize-implementation-notes/SKILL.md deleted file mode 100644 index 6da03e47..00000000 --- a/plugins/productize-all/skills/productize-implementation-notes/SKILL.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: productize-implementation-notes -description: >- - Running implementation-notes protocol for spec-driven builds. Use when the user asks the - agent to maintain implementation-notes.md or implementation-notes.html with decisions, - deviations, tradeoffs, open questions, and verification while implementing a feature, fix, - or product slice. ---- - - - -# Implementation Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `implementation-notes` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence - -Use this skill when implementation work needs a durable notes artifact that keeps -the user in the loop without stopping progress for every ambiguity. - -This is not a verbose work log. It records the meaningful places where the spec -was interpreted, narrowed, changed, or found incomplete. - -## Activation - -Activate alongside `$tdd`, `$eng-review`, `$qa`, or `$verification` when the user -asks for any of: - -- `implementation-notes.md` -- `implementation-notes.html` -- running implementation notes -- decisions the spec did not cover -- deviations from the spec -- tradeoffs made during implementation -- open questions to confirm after implementation - -Do not ask whether to create the file if the user already requested it. Create or -update the requested file and keep working. - -## File Selection - -- Use the exact path and format the user requested. -- If the user asks for notes but does not name a file, use `implementation-notes.md`. -- If the user asks for HTML, use `implementation-notes.html`. -- If an implementation-notes file already exists for the current task, update it - instead of overwriting useful existing context. - -## Update Cadence - -1. Create the notes file before or during the first implementation decision. -2. Update it when the implementation makes a non-obvious choice, interprets an - ambiguous spec line, departs from the spec, accepts a tradeoff, discovers an - open question, or changes verification scope. -3. Batch small related choices into one entry instead of writing noisy micro-logs. -4. Before claiming completion, do a final pass that aligns notes with the actual - diff, verification evidence, and unresolved questions. - -## What To Capture - -### Design Decisions - -Choices made where the spec was ambiguous or silent. - -Each entry should include: - -- decision -- reason -- spec basis, or `unspecified` -- impact - -### Deviations - -Intentional departures from the spec. - -Each entry should include: - -- requested behavior -- implemented behavior -- reason -- impact -- whether user confirmation is needed - -### Tradeoffs - -Alternatives considered and why the chosen path is better for this slice. - -Each entry should include: - -- chosen option -- alternatives considered -- why chosen -- cost or downside accepted - -### Open Questions - -Questions the user may want to confirm or revise. - -Each entry should include: - -- question -- why it matters -- current default assumption -- status: `needs-review`, `accepted-risk`, `resolved`, or `deferred` - -### Verification - -Evidence that proves the implementation and the notes are current. - -Include: - -- commands or checks run -- result -- coverage gaps -- behavior not tested - -## What Not To Capture - -- Every file edit. -- Internal reasoning or chain-of-thought. -- Obvious implementation details already specified. -- Secrets, credentials, private customer data, or raw logs with sensitive content. -- Generic progress narration that does not help the user review decisions. - -## Markdown Template - -Use this structure for Markdown notes: - -```markdown -# Implementation Notes - -## Spec Reference -[Feature, ticket, prompt, or artifact being implemented.] - -## Summary -[One paragraph describing how the implementation interprets the spec.] - -## Design Decisions -| Decision | Reason | Spec basis | Impact | -|---|---|---|---| - -## Deviations -| Requested | Implemented | Why | Impact | Confirmation | -|---|---|---|---|---| - -## Tradeoffs -| Choice | Alternatives | Why this path | Downside | -|---|---|---|---| - -## Open Questions -| Question | Why it matters | Current assumption | Status | -|---|---|---|---| - -## Verification -| Check | Result | Notes | -|---|---|---| -``` - -## HTML Template Rules - -For `implementation-notes.html`, produce a single self-contained HTML file: - -- embedded CSS and JavaScript only -- no external assets or remote dependencies unless explicitly requested -- semantic headings and landmarks -- responsive layout -- decision cards or tables for scanability -- status chips for `needs-review`, `accepted-risk`, `resolved`, and `deferred` -- a clear verification section near the bottom -- optional filters, collapsible detail, or copy buttons only when they help review - -Recommended HTML sections: - -1. **Header**: spec reference, implementation status, last updated, owner if known. -2. **Decision Dashboard**: counts for decisions, deviations, tradeoffs, open questions. -3. **Design Decisions**: cards or table with reason, spec basis, and impact. -4. **Deviations**: requested vs implemented, why, impact, confirmation status. -5. **Tradeoffs**: comparison table with accepted downside. -6. **Open Questions**: status and current default assumption. -7. **Verification**: commands/checks, results, and gaps. - -## Route Internally - -- `$tdd` -- `$eng-review` -- `$qa` -- `$verification` -- `$docs` -- `$release` - -## Required Output - -Return: - -1. **Notes File**: path, format, and whether it was created or updated. -2. **Captured Decisions**: decisions, deviations, tradeoffs, and open questions added. -3. **Spec Impact**: what downstream product, design, eng, QA, release, docs, or DX work may change. -4. **Verification Linkage**: checks run, gaps, and whether the notes match the final implementation. -5. **Next Review**: user confirmations or gate follow-ups needed. diff --git a/plugins/productize-all/skills/productize-implementation-notes/agents/openai.yaml b/plugins/productize-all/skills/productize-implementation-notes/agents/openai.yaml deleted file mode 100644 index b9985290..00000000 --- a/plugins/productize-all/skills/productize-implementation-notes/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Implementation Notes" - short_description: "Running implementation-notes protocol for spec-driven builds. Use when the user asks the agent to maintain..." - brand_color: "#334155" - default_prompt: "Use $productize-implementation-notes with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-industry-trend-strategy/SKILL.md b/plugins/productize-all/skills/productize-industry-trend-strategy/SKILL.md deleted file mode 100644 index 28c42dff..00000000 --- a/plugins/productize-all/skills/productize-industry-trend-strategy/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: productize-industry-trend-strategy -description: >- - Industry trend strategy. Use when the user needs a product workflow for product strategy - related to industry trend strategy. Trigger terms: strategy, competitive-analysis, - positioning, decision-making. ---- - - - -# Industry trend strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `industry-trend-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Industry trend strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INDUSTRY}} -- {{TREND}} -- {{COMPANY}} -- {{GOAL}} - - -GOAL -Produce a high-quality deliverable for: Industry trend strategy. -Success metric: -- Produces a grounded industry + trend analysis tied to company strengths and goal. -- Proposes at least three distinct strategies with actionable steps. -- Summarizes how strategies leverage strengths to achieve the goal. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{INDUSTRY}}`, `{{TREND}}`, `{{COMPANY}}`, and `{{GOAL}}`; if critical data is missing, state assumptions explicitly. -- Provide a concise industry + trend analysis and a focused company strengths assessment. -- Propose at least 3 distinct strategies aligned to strengths and goal. -- Each strategy must include name, description, alignment, contribution to goal, challenges, and action steps. -- Keep recommendations specific and actionable, not generic. - -FORMAT -Return exactly this structure: - - -[Industry + trend analysis and company strength assessment] - - - -1. [Strategy name] - - Description: [What it is] - - Alignment: [Company strengths leveraged] - - Contribution to goal: [How it advances the goal] - - Challenges: [Risks/obstacles] - - Action steps: [Concrete steps] -2. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -3. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -[Optional additional strategies] - - - -[Summary emphasizing how strategies leverage strengths to capitalize on the trend and achieve the goal] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 strategies are provided. -- Strategies lack alignment to company strengths or contribution to goal. -- Action steps are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-industry-trend-strategy/agents/openai.yaml b/plugins/productize-all/skills/productize-industry-trend-strategy/agents/openai.yaml deleted file mode 100644 index 29c1b914..00000000 --- a/plugins/productize-all/skills/productize-industry-trend-strategy/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Industry trend strategy" - short_description: "Industry trend strategy. Use when the user needs a product workflow for product strategy related to industry trend..." - brand_color: "#EA580C" - default_prompt: "Use $productize-industry-trend-strategy with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md b/plugins/productize-all/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md deleted file mode 100644 index 500376d5..00000000 --- a/plugins/productize-all/skills/productize-influence-strategies-from-cialdini-s-7-principles/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-influence-strategies-from-cialdini-s-7-principles -description: >- - Influence strategies from Cialdini's 7 principles. Use when the user needs a product - workflow for stakeholder management related to influence strategies from cialdini's 7 - principles. Trigger terms: influence, cialdini, stakeholder-management. ---- - - - -# Influence strategies from Cialdini's 7 principles - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `influence-strategies-from-cialdini-s-7-principles` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Influence strategies from Cialdini's 7 principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INFLUENCE_TARGET}} -- {{INFLUENCE_GOAL}} - - -GOAL -Produce a high-quality deliverable for: Influence strategies from Cialdini's 7 principles. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate influence ideas tailored to `{{INFLUENCE_TARGET}}` and `{{INFLUENCE_GOAL}}`. -- Provide at least one specific, actionable, ethical idea for each Cialdini principle: -- Reciprocity -- Liking -- Unity -- Authority -- Social Proof -- Consistency -- Scarcity -- For each idea, include a clear strategy and rationale tied to the target context and goal. -- Use professional, non-manipulative tactics that create value for both sides. - -FORMAT -Return exactly this structure: - - - -Name of the principle -Detailed description of the strategy or tactic -Explanation of why this idea would be effective for the given target and goal - -(Repeat this structure for each of the seven principles) - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Not all seven principles are covered, or principles are duplicated while another is missing. -- Strategies are generic, unethical/manipulative, or not tied to the target and goal. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-influence-strategies-from-cialdini-s-7-principles/agents/openai.yaml b/plugins/productize-all/skills/productize-influence-strategies-from-cialdini-s-7-principles/agents/openai.yaml deleted file mode 100644 index c17f45c0..00000000 --- a/plugins/productize-all/skills/productize-influence-strategies-from-cialdini-s-7-principles/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Influence strategies from Cialdini's 7 principles" - short_description: "Influence strategies from Cialdini's 7 principles. Use when the user needs a product workflow for stakeholder..." - brand_color: "#0891B2" - default_prompt: "Use $productize-influence-strategies-from-cialdini-s-7-principles with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-innovation-decision-making-heuristics/SKILL.md b/plugins/productize-all/skills/productize-innovation-decision-making-heuristics/SKILL.md deleted file mode 100644 index 710886c0..00000000 --- a/plugins/productize-all/skills/productize-innovation-decision-making-heuristics/SKILL.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -name: productize-innovation-decision-making-heuristics -description: >- - Design tailored decision-making heuristics for uncertain innovation work. Use when the user - needs simple decision rules for product bets, discovery, investment, pivot, prioritization, - or opportunity selection in noisy and changing contexts. ---- - - - -# Innovation Decision Making Heuristics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovation-decision-making-heuristics` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop - -Use this skill when a team needs a practical decision rule, not a one-off recommendation. -The output should help the team decide repeatedly under uncertainty while avoiding arbitrary -or off-the-shelf rules. - -## Decision-Making Principles - -- Heuristics are useful shortcuts when the environment is noisy, dynamic, uncertain, or - time-sensitive and more information does not necessarily clarify direction. -- Heuristics fail when applied blindly, when nuance matters, or when the environment is stable - enough for more complete analysis. -- Effective heuristics should come from the user's real business challenge, constraints, - evidence, and observed feedback. -- A good heuristic makes tradeoffs explicit: speed versus accuracy, exploration versus focus, - safety versus moonshot, and learning versus commitment. -- Heuristics must be reviewed and refined through practical experience. - -## Workflow - -1. Identify the recurring decision type and the context in which it appears. -2. Classify the environment: noisy/dynamic/uncertain, stable, time-sensitive, multi-factor, - politically loaded, or high-stakes irreversible. -3. Define what the heuristic should optimize: learning, speed, risk control, focus, upside, - user value, revenue, retention, or strategic fit. -4. Identify where naive heuristics could fail. -5. Create 3-5 tailored decision rules with explicit triggers and exceptions. -6. Add a feedback loop so the rule can improve after use. - -## Output Contract - -Return: - -```markdown -# Innovation Decision Making Heuristics - -## 1. Recurring Decision -Decision type: -Who decides: -Frequency: -Time pressure: -Stakes: - -## 2. Decision Environment -Context: -Noise / uncertainty: -Information quality: -Reversibility: -Stable analysis possible: - -## 3. What The Rules Should Optimize -Primary objective: -Secondary objective: -Tradeoff to accept: -Tradeoff to avoid: - -## 4. Heuristic Failure Risks -Where shortcuts help: -Where shortcuts fail: -Bias risks: -Escalation or sunk-cost risk: - -## 5. Tailored Decision Rules -Rule 1: -Use when: -Exception: -Evidence needed: - -Rule 2: -Use when: -Exception: -Evidence needed: - -Rule 3: -Use when: -Exception: -Evidence needed: - -## 6. Feedback And Refinement -Signal to track: -Review cadence: -Who updates the rule: -When to retire the rule: -``` - -## Failure Modes - -- Provides generic principles instead of concrete decision rules. -- Creates rules that ignore the user's actual uncertainty, constraints, and feedback loops. -- Treats heuristics as always good or always bad rather than context-dependent. -- Omits exceptions and review mechanisms. diff --git a/plugins/productize-all/skills/productize-innovation-decision-making-heuristics/agents/openai.yaml b/plugins/productize-all/skills/productize-innovation-decision-making-heuristics/agents/openai.yaml deleted file mode 100644 index 1c8dfcb8..00000000 --- a/plugins/productize-all/skills/productize-innovation-decision-making-heuristics/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovation Decision Making Heuristics" - short_description: "Design tailored decision-making heuristics for uncertain innovation work. Use when the user needs simple decision..." - brand_color: "#7C2D12" - default_prompt: "Use $productize-innovation-decision-making-heuristics with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md b/plugins/productize-all/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md deleted file mode 100644 index fe4b11dc..00000000 --- a/plugins/productize-all/skills/productize-innovative-idea-generation-from-project-parameters-and/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-project-parameters-and -description: >- - Innovative idea generation from project parameters and constraints. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, - product-management, osborn-checklist. ---- - - - -# Innovative idea generation from project parameters and constraints - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-project-parameters-and` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from project parameters and constraints**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_TYPE}} -- {{GOALS}} -- {{BUDGET}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from project parameters and constraints". -Success metric: -- Produces concrete, non-generic ideas that fit project type, goals, and budget. -- Uses structured creativity analysis (including Osborn checklist) to move beyond obvious solutions. -- Final ideas are immediately actionable with clear execution steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_TYPE}}`, `{{GOALS}}`, and `{{BUDGET}}`; if details are missing, state assumptions explicitly. -- Provide exactly 5 banal ideas to avoid and explain why each is weak. -- Define problem context including timeframe, target audience, and situation. -- Break down problem into objective, constraints, measurable success criteria, challenges, and deeper considerations. -- Analyze each chunk with explicit link to goals and budget feasibility. -- Include both creator and consumer perspectives. -- Apply Osborn checklist categories with project-relevant outputs: - - other uses, adaptations, modifications, magnification, minification, substitutions, rearrangements, reversals, combinations. -- Final ideas must be actionable for an individual, feasible under budget, and include step-by-step instructions plus application context. - -FORMAT -Return exactly this structure: - - - -1. [Banal idea] - [Why to avoid] -2. [Banal idea] - [Why to avoid] -3. [Banal idea] - [Why to avoid] -4. [Banal idea] - [Why to avoid] -5. [Banal idea] - [Why to avoid] - - - -[Clearly define the problem or situation] - - - -[Break down the problem into key aspects] - - - -[Provide in-depth analysis of each problem chunk] - - - -[Describe creator and consumer perspectives] - - - -- Other uses: [Ideas] -- Adaptations: [Ideas] -- Modifications: [Ideas] -- Magnification: [Ideas] -- Minification: [Ideas] -- Substitutions: [Ideas] -- Rearrangements: [Ideas] -- Reversals: [Ideas] -- Combinations: [Ideas] - - - -1. [Idea title] - - Specific guidance: [What to do] - - Steps: [Step-by-step] - - Where/how to apply: [Context/channel/tool] - - Budget fit: [How it stays within budget] -[Repeat for additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `banal_ideas` does not contain exactly 5 items. -- One or more Osborn checklist categories are missing. -- Final ideas are not actionable step-by-step or are not aligned to budget/goals. -- Output is generic or repeats clichรฉ ideas without meaningful differentiation. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-innovative-idea-generation-from-project-parameters-and/agents/openai.yaml b/plugins/productize-all/skills/productize-innovative-idea-generation-from-project-parameters-and/agents/openai.yaml deleted file mode 100644 index d0ca290b..00000000 --- a/plugins/productize-all/skills/productize-innovative-idea-generation-from-project-parameters-and/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovative idea generation from project parameters and constraints" - short_description: "Innovative idea generation from project parameters and constraints. Use when the user needs a product workflow for..." - brand_color: "#0D9488" - default_prompt: "Use $productize-innovative-idea-generation-from-project-parameters-and with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md b/plugins/productize-all/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 3a22d36f..00000000 --- a/plugins/productize-all/skills/productize-innovative-idea-generation-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -name: productize-innovative-idea-generation-from-structured-brainstorming -description: >- - Innovative idea generation from structured brainstorming techniques. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, - creativity, product-discovery, problem-solving. ---- - - - -# Innovative idea generation from structured brainstorming techniques - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from structured brainstorming techniques**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from structured brainstorming techniques". -Success metric: -- Produces a structured ideation session using free association, mind mapping, SCAMPER, and bias checks. -- Generates non-obvious, high-potential ideas grounded in the topic. -- Outputs clear top ideas with rationale and a concise synthesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run a complete structured ideation flow: - - free association (4-6 rounds), - - mind map (3-4 levels), - - SCAMPER exploration (2-3 rounds across shortlisted branches), - - bias check, - - top-idea selection and rationale. -- Avoid clichรฉd or overhyped ideas; prioritize specificity and novelty. -- Ensure top ideas are distinct from one another and clearly connected to generated branches. -- Keep outputs practical enough to be explored/prototyped next. - -FORMAT -Return exactly this structure: - - - -[4-6 rounds of free associations tied to `{{TOPIC}}`] - - - -[Mind map with 3-4 branching levels derived from free associations] - - - -1. [Branch] -2. [Branch] -3. [Branch] - - - -[2-3 rounds applying SCAMPER prompts to shortlisted branches] - - - -- Anchoring check: [Findings/adjustment] -- Status quo check: [Findings/adjustment] -- Groupthink check: [Findings/adjustment] - - - -1. [Idea 1] -2. [Idea 2] -3. [Idea 3] - - - -1. [Why idea 1 is powerful and non-obvious] -2. [Why idea 2 is powerful and non-obvious] -3. [Why idea 3 is powerful and non-obvious] - - - - -1. [Idea 1]: [Rationale] -2. [Idea 2]: [Rationale] -3. [Idea 3]: [Rationale] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `freeassociation` has fewer than 4 rounds or more than 6 rounds. -- `mindmap` does not show 3-4 levels of branching. -- `scamper` does not include at least 2 rounds. -- `top_ideas` does not contain exactly 3 distinct ideas. -- Rationales are generic and do not explain non-obvious value. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-innovative-idea-generation-from-structured-brainstorming/agents/openai.yaml b/plugins/productize-all/skills/productize-innovative-idea-generation-from-structured-brainstorming/agents/openai.yaml deleted file mode 100644 index fdcf1b79..00000000 --- a/plugins/productize-all/skills/productize-innovative-idea-generation-from-structured-brainstorming/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovative idea generation from structured brainstorming techniques" - short_description: "Innovative idea generation from structured brainstorming techniques. Use when the user needs a product workflow for..." - brand_color: "#0D9488" - default_prompt: "Use $productize-innovative-idea-generation-from-structured-brainstorming with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md b/plugins/productize-all/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 0ccf894a..00000000 --- a/plugins/productize-all/skills/productize-innovative-product-ideas-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -name: productize-innovative-product-ideas-from-structured-brainstorming -description: >- - Innovative product ideas from structured brainstorming. Use when the user needs a product - workflow for ideation & creativity related to innovative product ideas from structured - brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, - product-management. ---- - - - -# Innovative product ideas from structured brainstorming - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-product-ideas-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative product ideas from structured brainstorming**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative product ideas from structured brainstorming". -Success metric: -- Produces a complete structured brainstorming session from divergence to convergence. -- Generates non-obvious product ideas grounded in the topic and validated via bias checks. -- Returns exactly 3 top ideas with clear innovation rationale in abstract terms. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run all stages: free association, mind map, SCAMPER expansion, bias check, top-idea selection, summary. -- Avoid banal, overhyped, or clichรฉd outputs. -- Top ideas must be described abstractly; do not use specific tech buzzwords such as `AI`, `blockchain`, or `VR`. -- Ensure ideas are distinct and traceable to earlier brainstorming artifacts. - -FORMAT -Return exactly this structure: - - - - -1. [Word or phrase] -2. [Word or phrase] -... -[Total 8-10 items] - - - -[Topic] -- [Main branch 1] - - [Sub-branch 1a] - - [Sub-branch 1b] -- [Main branch 2] - - [Sub-branch 2a] - - [Sub-branch 2b] -- [Main branch 3] - - [Sub-branch 3a] - - [Sub-branch 3b] -[At least 3 main branches; each with 2-3 sub-branches] - - - -- Branch: [Name] - - Technique 1: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] - - Technique 2: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] -[Repeat for 3 branches] - - - -- Bias: [Name] - - Evidence in ideas: [How it appears] - - Countermeasure: [Concrete action] -[At least 1 bias] - - - -1. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -2. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -3. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] - - - -[Brief recap of process and why final ideas are stronger after SCAMPER and bias checks] - - - - -FAILURE -- Root tag `` or any required sub-tag is missing, malformed, or incomplete. -- `free_association` has fewer than 8 or more than 10 items. -- `mind_map` has fewer than 3 main branches or insufficient sub-branches. -- `scamper` does not cover 3 branches with 2 techniques each. -- `top_ideas` does not contain exactly 3 ideas. -- Top ideas include banned specific-technology terms (`AI`, `blockchain`, `VR`). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-innovative-product-ideas-from-structured-brainstorming/agents/openai.yaml b/plugins/productize-all/skills/productize-innovative-product-ideas-from-structured-brainstorming/agents/openai.yaml deleted file mode 100644 index c25e684b..00000000 --- a/plugins/productize-all/skills/productize-innovative-product-ideas-from-structured-brainstorming/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovative product ideas from structured brainstorming" - short_description: "Innovative product ideas from structured brainstorming. Use when the user needs a product workflow for ideation &..." - brand_color: "#0D9488" - default_prompt: "Use $productize-innovative-product-ideas-from-structured-brainstorming with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-interactive-intake-for-ost-inputs/SKILL.md b/plugins/productize-all/skills/productize-interactive-intake-for-ost-inputs/SKILL.md deleted file mode 100644 index 7353afd5..00000000 --- a/plugins/productize-all/skills/productize-interactive-intake-for-ost-inputs/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: productize-interactive-intake-for-ost-inputs -description: >- - Interactive intake for OST inputs. Use when the user needs a product workflow for user - research related to interactive intake for ost inputs. Trigger terms: user-research, ost, - continuous-discovery. ---- - - - -# Interactive intake for OST inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `interactive-intake-for-ost-inputs` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Interactive intake for OST inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Interactive intake for OST inputs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Act as an intake orchestrator for downstream OST inputs. -- Parse existing user-provided context first, then ask only missing critical questions. -- Collect and normalize exactly four variables: -- `{{business_outcome}}`: one concise, outcome-focused sentence (no solution wording). -- `{{journey_nodes_as_list}}`: JSON array of distinct journey moments (not features). -- `{{interview_transcripts_or_story_snippets}}`: markdown snippets with attribution and timestamps when available. -- `{{constraints_or_principles}}`: short markdown list/sentence or `None stated`. -- Apply quality guards: -- Reframe solution-flavored outcomes into measurable outcomes. -- Rephrase feature-like nodes into moments in time. -- Add minimal attribution labels when transcript context is sparse. -- Stop only when all four fields are present, clear, distinct, normalized, and confirmed. - -FORMAT -Return exactly this structure: - -{{business_outcome}}: [one concise, outcome-focused sentence] - -{{journey_nodes_as_list}}: ["[Moment 1]", "[Moment 2]", "[Moment 3]"] - -{{interview_transcripts_or_story_snippets}}: -[markdown transcript/snippets with speaker labels and timestamps if available] - -{{constraints_or_principles}}: -[short markdown list or sentence; if none provided, write "None stated"] - -FAILURE -- Any of the four required variables is missing or malformed. -- `{{business_outcome}}` is solution-flavored or not measurable/outcome-oriented. -- `{{journey_nodes_as_list}}` is not valid JSON array syntax or contains features instead of moments. -- Interview material lacks usable attribution/context when source data allows it. -- Constraints field is omitted instead of explicitly set to `None stated`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-interactive-intake-for-ost-inputs/agents/openai.yaml b/plugins/productize-all/skills/productize-interactive-intake-for-ost-inputs/agents/openai.yaml deleted file mode 100644 index 5680df22..00000000 --- a/plugins/productize-all/skills/productize-interactive-intake-for-ost-inputs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Interactive intake for OST inputs" - short_description: "Interactive intake for OST inputs. Use when the user needs a product workflow for user research related to..." - brand_color: "#0D9488" - default_prompt: "Use $productize-interactive-intake-for-ost-inputs with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-lean-canvas/SKILL.md b/plugins/productize-all/skills/productize-lean-canvas/SKILL.md deleted file mode 100644 index b3a18d33..00000000 --- a/plugins/productize-all/skills/productize-lean-canvas/SKILL.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -name: productize-lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- - - - -# Lean Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `lean-canvas` -- **Lifecycle**: Think -- **Category**: Business Model -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/plugins/productize-all/skills/productize-lean-canvas/agents/openai.yaml b/plugins/productize-all/skills/productize-lean-canvas/agents/openai.yaml deleted file mode 100644 index 8f6a8b20..00000000 --- a/plugins/productize-all/skills/productize-lean-canvas/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Lean Canvas" - short_description: "Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and..." - brand_color: "#9333EA" - default_prompt: "Use $productize-lean-canvas with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md b/plugins/productize-all/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md deleted file mode 100644 index 672e4be9..00000000 --- a/plugins/productize-all/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-limit-based-product-strategy-from-problem-to-execution-plan -description: >- - Limit-based product strategy from problem to execution plan. Use when the user needs a - product workflow for product strategy related to limit-based product strategy from problem - to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, - structured-thinking. ---- - - - -# Limit-based product strategy from problem to execution plan - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `limit-based-product-strategy-from-problem-to-execution-plan` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Limit-based product strategy from problem to execution plan**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Produce a high-quality deliverable for: Limit-based product strategy from problem to execution plan. -Success metric: -- Applies the full Limit-Based Product Thinking framework end-to-end. -- Produces concrete milestones, levers, assumptions, and a phased execution plan. -- Keeps outputs grounded in the provided problem statement. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM_STATEMENT}}`; if critical details are missing, state assumptions explicitly. -- Follow all 7 framework steps in order. -- Provide quantified convergence milestones at 10%, 25%, 50%, 75%, 90% with dates or triggers. -- Identify levers to accelerate convergence and explicitly name the top 1โ€“2 highest impact moves. -- List critical assumptions with validation methods. -- Provide a 3-phase plan (Foundation, Acceleration, Optimization) with timelines and resource guidance. - -FORMAT -Return exactly this structure: - - -1. Growth Variable: [Your identified variable] - -2. Limit State Description: - [Your vivid description of the fully mature state] - -3. Core Properties of the Limit: - [List of key features and interactions] - -4. Convergence Estimate: - [Growth curve and milestones] - -5. Acceleration Strategies: - [Prioritized list of levers to steepen the curve] - -6. Critical Assumptions: - [List of assumptions with validation methods] - -7. Product Vision and Execution: - Vision Statement: [One-sentence summary] - Roadmap: [Major milestones and timelines] - 3-Phase Plan: [Brief outline of each phase] - Resource Allocation: [Key recommendations] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Convergence milestones are missing required percentages or triggers/dates. -- Acceleration strategies lack prioritized top 1โ€“2 levers. -- Assumptions lack validation methods. -- 3-phase plan is missing or not sequenced. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/agents/openai.yaml b/plugins/productize-all/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/agents/openai.yaml deleted file mode 100644 index d25dda5f..00000000 --- a/plugins/productize-all/skills/productize-limit-based-product-strategy-from-problem-to-execution-plan/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Limit-based product strategy from problem to execution plan" - short_description: "Limit-based product strategy from problem to execution plan. Use when the user needs a product workflow for product..." - brand_color: "#059669" - default_prompt: "Use $productize-limit-based-product-strategy-from-problem-to-execution-plan with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md b/plugins/productize-all/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md deleted file mode 100644 index 110f89a8..00000000 --- a/plugins/productize-all/skills/productize-low-frequency-to-power-user-transition-strategy/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: productize-low-frequency-to-power-user-transition-strategy -description: >- - Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow - for product strategy related to low-frequency-to-power-user transition strategy. Trigger - terms: product-strategy, engagement, activation, retention. ---- - - - -# Low-Frequency-to-Power-User Transition Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `low-frequency-to-power-user-transition-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Low-Frequency-to-Power-User Transition Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_DESCRIPTION}} -- {{CURRENT_USE_CASE}} -- {{TARGET_USE_CASE}} - - -GOAL -Produce a high-quality deliverable for: Low-Frequency-to-Power-User Transition Strategy. -Success metric: -- Produces a concrete transition plan from low-frequency to high-frequency usage. -- Aligns strategy to current and target use cases with explicit behavioral gaps. -- Includes metrics, timeline, and rollout/education plans grounded in the inputs. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_DESCRIPTION}}`, `{{CURRENT_USE_CASE}}`, and `{{TARGET_USE_CASE}}`; if information is missing, state assumptions explicitly. -- Identify the behavioral gap between current and target usage. -- Provide step-by-step transition plan, education/onboarding, and communication strategy. -- Include rollout plan, key metrics, and timeline for measurement. -- Keep recommendations specific and grounded in the provided context. - -FORMAT -Return exactly this structure: - - -1. Current Use Case Analysis: - [Provide a brief analysis of the current low-frequency use case] - -2. Target Use Case Analysis: - [Provide a brief analysis of the target high-frequency use case] - -3. User Behavior and Needs: - [Summarize key insights about user behavior and needs] - -4. Transition Strategy: - a. Feature Introduction Plan: - [Outline the step-by-step plan for introducing new features] - b. User Education and Onboarding: - [Describe the approach for educating users about the new use case] - c. Communication Strategy: - [Outline the key messages and channels for communicating the benefits] - d. Gradual Rollout Plan: - [Describe the approach for gradually introducing new functionality] - -5. Implementation and Measurement: - a. Key Metrics: - [List the primary metrics to track for measuring success] - b. Timeline: - [Provide a high-level timeline for implementation and evaluation] - c. Feedback and Iteration: - [Describe the plan for collecting user feedback and making improvements] - -6. Potential Challenges and Mitigation Strategies: - [Identify potential obstacles and propose solutions] - -7. Conclusion: - [Summarize the key points of the transition strategy and its potential impact] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Behavioral gap or barriers are not explicitly identified. -- Metrics or timeline are missing. -- Strategies are generic or not tied to the given use cases. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-low-frequency-to-power-user-transition-strategy/agents/openai.yaml b/plugins/productize-all/skills/productize-low-frequency-to-power-user-transition-strategy/agents/openai.yaml deleted file mode 100644 index 93a82645..00000000 --- a/plugins/productize-all/skills/productize-low-frequency-to-power-user-transition-strategy/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Low-Frequency-to-Power-User Transition Strategy" - short_description: "Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow for product strategy..." - brand_color: "#C2410C" - default_prompt: "Use $productize-low-frequency-to-power-user-transition-strategy with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-managerial-finance-dcf/SKILL.md b/plugins/productize-all/skills/productize-managerial-finance-dcf/SKILL.md deleted file mode 100644 index 6b191136..00000000 --- a/plugins/productize-all/skills/productize-managerial-finance-dcf/SKILL.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -name: productize-managerial-finance-dcf -description: >- - Productize Finance engine for time value of money, DCF, NPV, IRR, payback, free cash flow, - terminal value, project valuation, mutually exclusive investments, and whether growth - creates or destroys value. ---- - - - -# Managerial Finance DCF - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `managerial-finance-dcf` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings - -## Purpose - -Core investment-decision skill for evaluating projects and cash-flow streams. -Use it when comparing investments, building free cash flow forecasts, calculating -NPV/IRR/payback, estimating terminal value, or judging whether growth creates value. - -## Core Formulas - -- `FV_t = C_0 * (1 + r)^t` -- `PV = C_t / (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(C_t / (1 + r)^t)` -- `NPV with TV = -I_0 + sum(FCF_t / (1 + r)^t) + TV_N / (1 + r)^N` -- `0 = -I_0 + sum(C_t / (1 + IRR)^t)` -- `Profitability Index = PV of Future Cash Flows / Initial Investment` -- `FCF = EBIT * (1 - T_c) + Depreciation - CapEx - Delta NWC` -- `NOPAT = EBIT * (1 - T_c)` -- `TV_N = FCF_{N+1} / (r - g)` with `r > g` -- `ROIC = NOPAT / Invested Capital` -- `Reinvestment Rate = (CapEx - Depreciation + Delta NWC) / NOPAT` -- `g = ROIC * Reinvestment Rate` - -## Decision Rules - -- Independent projects: accept if `NPV > 0`; reject if `NPV < 0`. -- Mutually exclusive projects: choose the highest NPV. -- IRR supports the decision, but warn when cash flows change sign more than once, - projects differ in scale or timing, or multiple/no real IRRs exist. -- Growth creates value only when `ROIC > WACC`; it destroys value when `ROIC < WACC`. - -## Required Functions - -Use `$finance-modeling-kernel` functions for PV/FV, streams, NPV, IRR, payback, -discounted payback, annuities, perpetuities, free cash flow, terminal value, -ROIC, reinvestment rate, and sustainable growth. - -## Required Validation - -- Warn if comparing undiscounted cash flows across time. -- Warn if terminal growth exceeds long-run economic growth. -- Reject `g >= r` in growing perpetuity. -- Warn if IRR conflicts with NPV. -- Warn if payback is used as the final decision rule. -- Warn if sunk costs, financing cash flows, non-incremental overhead, cannibalization, - or opportunity cost are mishandled. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Make NPV the primary investment decision rule. diff --git a/plugins/productize-all/skills/productize-managerial-finance-dcf/agents/openai.yaml b/plugins/productize-all/skills/productize-managerial-finance-dcf/agents/openai.yaml deleted file mode 100644 index d700fdd2..00000000 --- a/plugins/productize-all/skills/productize-managerial-finance-dcf/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Managerial Finance DCF" - short_description: "Productize Finance engine for time value of money, DCF, NPV, IRR, payback, free cash flow, terminal value, project..." - brand_color: "#0369A1" - default_prompt: "Use $productize-managerial-finance-dcf with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-map-power-dynamics-before-meetings/SKILL.md b/plugins/productize-all/skills/productize-map-power-dynamics-before-meetings/SKILL.md deleted file mode 100644 index 6bfe5f9f..00000000 --- a/plugins/productize-all/skills/productize-map-power-dynamics-before-meetings/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: productize-map-power-dynamics-before-meetings -description: >- - Map power dynamics before meetings. Use when the user needs a product workflow for - stakeholder management related to map power dynamics before meetings. Trigger terms: - stakeholders, power-dynamics, meetings, communication. ---- - - - -# Map power dynamics before meetings - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `map-power-dynamics-before-meetings` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Map power dynamics before meetings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DETAILS}} -- {{ATTENDEES_INFO}} - - -GOAL -Produce a high-quality deliverable for: "Map power dynamics before meetings". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{MEETING_DETAILS}}` and `{{ATTENDEES_INFO}}` to map meeting-specific power dynamics. -- Identify formal hierarchy, informal influence signals, alliances/conflicts, and each attendee's stake in outcomes. -- Rank attendees by influence in this meeting context. -- Identify decision-makers, influencers, power imbalances, and likely conflict points. -- Provide actionable strategies to navigate dynamics during the meeting. -- If information is insufficient for any claim, explicitly state the uncertainty. - -FORMAT -Return exactly this structure: - - - -[List attendees in order of influence, with brief notes on their power sources] - - - -[Bullet points of important observations about the power dynamics] - - - -[Bullet points of strategies to navigate the power dynamics effectively] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Influence ranking is not meeting-contextual or lacks power-source rationale. -- Recommendations are generic or not tied to identified dynamics/conflicts. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-map-power-dynamics-before-meetings/agents/openai.yaml b/plugins/productize-all/skills/productize-map-power-dynamics-before-meetings/agents/openai.yaml deleted file mode 100644 index 89ad24e8..00000000 --- a/plugins/productize-all/skills/productize-map-power-dynamics-before-meetings/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Map power dynamics before meetings" - short_description: "Map power dynamics before meetings. Use when the user needs a product workflow for stakeholder management related to..." - brand_color: "#0891B2" - default_prompt: "Use $productize-map-power-dynamics-before-meetings with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md b/plugins/productize-all/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md deleted file mode 100644 index 1cb24d45..00000000 --- a/plugins/productize-all/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: productize-market-opportunities-from-jobs-to-be-done-market-canvas -description: >- - Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product - workflow for product strategy related to market opportunities from jobs-to-be-done market - canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, - product-strategy. ---- - - - -# Market opportunities from Jobs-to-be-Done market canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunities-from-jobs-to-be-done-market-canvas` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path - -Use this skill to run the Productize prompt contract for **Market opportunities from Jobs-to-be-Done market canvas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_OR_SERVICE}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Market opportunities from Jobs-to-be-Done market canvas. -Success metric: -- Guides the user through all 8 JTBD canvas steps with clear prompts. -- Keeps responses tied to provided `{{USER_INPUT}}` and the product context. -- Ends with a concise summary prompt that reflects the completed canvas. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_OR_SERVICE}}` and `{{USER_INPUT}}`; if context is missing, state assumptions explicitly. -- Ask for user input at each of the 8 JTBD canvas steps. -- Provide a brief explanation before each stepโ€™s prompt. -- Require the user to answer within the specified `` tags. -- End by requesting a `` that synthesizes the full canvas. -- Remind the user to use `{{USER_INPUT}}` when answering. - -FORMAT -Return exactly this structure: - - -[Prompt + explanation for Traditional Market Definition] - - - -[Prompt + explanation for Job Executor Determination] - - - -[Prompt + explanation for Abstracted Job Executor] - - - -[Prompt + explanation for Job Executor Documentation] - - - -[Prompt + explanation for Product Function Analysis] - - - -[Prompt + explanation for Complementary Product Analysis] - - - -[Prompt + explanation for Job Statement Abstraction] - - - -[Prompt + explanation for Final Job Documentation] - - - -[Prompt asking the user to summarize the completed canvas] - - -FAILURE -- Any required step tag in `FORMAT` is missing, malformed, or incomplete. -- Prompts do not request user responses within the correct `` tags. -- User is not reminded to use `{{USER_INPUT}}` for responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/agents/openai.yaml b/plugins/productize-all/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/agents/openai.yaml deleted file mode 100644 index f6f266be..00000000 --- a/plugins/productize-all/skills/productize-market-opportunities-from-jobs-to-be-done-market-canvas/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market opportunities from Jobs-to-be-Done market canvas" - short_description: "Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product workflow for product..." - brand_color: "#0F766E" - default_prompt: "Use $productize-market-opportunities-from-jobs-to-be-done-market-canvas with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-market-opportunity/SKILL.md b/plugins/productize-all/skills/productize-market-opportunity/SKILL.md deleted file mode 100644 index bf55ae97..00000000 --- a/plugins/productize-all/skills/productize-market-opportunity/SKILL.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -name: productize-market-opportunity -description: >- - Identify, compare, and choose market opportunities for a venture, product, technology, or - innovation. Use when a founder, entrepreneur, product team, or innovator is choosing which - market to enter, picking a primary customer segment, evaluating whether a technology has - better use cases, deciding whether to pivot, comparing growth options, framing a venture for - investors, or asking variants of "which market should I target", "is this the right - opportunity", "where should I focus", "should I pivot", or "what else could this be used - for". Produces filled-in opportunity canvases for the Market Opportunity Set, Attractiveness - Map, Focus Portfolio Map, and Focus Strategy. Default to this skill when the question is - where to play rather than how to play. ---- - - - -# Market Opportunity - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunity` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market Opportunity venture brief with target segment, wedge, assumptions, and validation path - -Create the complete four-part market opportunity artifact set for choosing where a -venture, technology, product, or innovation should play. - -Use neutral terms such as `canvas`, `opportunity artifact`, `strategy surface`, or the -artifact names below. - -## Argument Hint - -`` - -## Usage - -```text -/market-opportunity $ARGUMENTS -``` - -## Required Artifacts - -For any complete request, create all four artifacts unless the user explicitly asks for -only one: - -1. **Opportunity Overview Canvas**: the three-part overview with opportunity set, - attractiveness map, and focus portfolio map. -2. **Opportunity Set Builder**: abilities -> applications -> customers -> market - opportunities. -3. **Attractiveness Evaluator**: potential and challenge ratings for each market - opportunity. -4. **Focus Portfolio Planner**: primary market opportunity, backup options, growth - options, and pursue/keep/store decisions. - -Load `references/canonical-canvases.md` before creating blank templates, filled -templates, printable layouts, or tables. It defines the exact fields and structure. - -Load `references/rating-and-decision-rules.md` before rating opportunities, -classifying map zones, or recommending primary, backup, and growth options. - -Load `references/output-formats.md` when the user asks for Markdown, HTML, PDF, -slides, visual canvases, or printable templates. - -## Workflow - -### 1. Establish the Input Mode - -Determine whether the user wants: - -- **Blank canvas set**: empty structured artifacts for a team to fill in. -- **Filled canvas set**: completed artifacts from a venture/product/technology idea. -- **Opportunity review**: critique or improve an existing opportunity set. -- **Strategy decision**: choose the primary opportunity and portfolio options. -- **Printable artifact**: create visual HTML/PDF/slide-ready canvases. - -If context is missing, ask only for the smallest useful missing piece: - -- The venture, product, technology, or core ability. -- Candidate applications. -- Candidate customer groups. -- Existing evidence for demand, market size, economics, implementation, timing, and risks. - -### 2. Generate the Market Opportunity Set - -Identify the venture's core abilities or technological elements first. Describe them -independent of the envisioned product. - -Then generate combinations: - -```text -market opportunity = application + customer segment -``` - -Segment customers precisely. Avoid broad labels like "enterprises" or "consumers" -unless the user has no better information. - -### 3. Evaluate Attractiveness - -For each market opportunity, rate: - -- **Potential** - - Compelling reason to buy. - - Market volume. - - Economic viability. -- **Challenge** - - Implementation obstacles. - - Time to revenue. - - External risks. - -Use the four-level rating scale: - -```text -Low / Mid / High / Super High -``` - -Then place each opportunity on the attractiveness map: - -- **Gold Mine** -- **Quick Win** -- **Moon Shot** -- **Questionable** - -### 4. Design the Focus Portfolio - -Choose one **Primary Market Opportunity** based on attractiveness and strategic fit. - -For other attractive opportunities, assess relatedness to the primary opportunity: - -- **Product relatedness**: shared technological competences, required resources, - and necessary networks. -- **Market relatedness**: shared customer values and benefits, sales channels, and - word-of-mouth paths. - -Classify each option: - -- **Growth Option**: attractive and useful for creating additional value. -- **Backup Option**: attractive and does not share major risks with the primary path. -- **Storage**: documented but not worth active preservation now. - -Make one of three action decisions for each option: - -- Pursue now. -- Keep open. -- Place in storage. - -The final strategy must keep at least one credible backup option and one credible -growth option open unless the available evidence makes that impossible. If impossible, -say what evidence or opportunity generation is missing. - -### 5. Tie Strategy to Execution - -For completed strategy outputs, include implications for: - -- Product and technology modularity. -- IP and defensibility. -- Hiring and capability development. -- Stakeholder and investor alignment. -- Brand and market communication. -- Experiments, assumptions, and learning loops. -- Business Model Canvas, Value Proposition Canvas, and Lean Startup integration when - the user asks for execution planning. - -## Output Rules - -- Preserve the canonical field names and rating scales from the reference files. -- Do not collapse the framework into SWOT, generic market sizing, or a feature - prioritization matrix. -- Be explicit about assumptions and evidence gaps. -- Use tables for editable outputs. -- For visual outputs, use the same four-artifact structure and neutral artifact titles. -- Do not copy long passages from source PDFs. Use the exact operational labels and - schemas, with original wording for explanations and recommendations. diff --git a/plugins/productize-all/skills/productize-market-opportunity/agents/openai.yaml b/plugins/productize-all/skills/productize-market-opportunity/agents/openai.yaml deleted file mode 100644 index f15444f5..00000000 --- a/plugins/productize-all/skills/productize-market-opportunity/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market Opportunity" - short_description: "Identify, compare, and choose market opportunities for a venture, product, technology, or innovation. Use when a..." - brand_color: "#0F766E" - default_prompt: "Use $productize-market-opportunity with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-market-opportunity/references/canonical-canvases.md b/plugins/productize-all/skills/productize-market-opportunity/references/canonical-canvases.md deleted file mode 100644 index a3c436db..00000000 --- a/plugins/productize-all/skills/productize-market-opportunity/references/canonical-canvases.md +++ /dev/null @@ -1,234 +0,0 @@ -# Canonical Market Opportunity Canvases - -Use these four canvases as the canonical output surfaces. Use neutral artifact names in -user-facing output. - -## 1. Opportunity Overview Canvas - -Purpose: show the entire flow from opportunity generation to attractiveness placement -to focus portfolio decision. - -Required fields: - -- Name. -- Date. -- Title: `Market Opportunity Overview`. -- Market opportunity definition: `application + customer`. -- Left panel: **Market Opportunity Set**. -- Middle panel: **Attractiveness Map**. -- Right panel: **Focus Portfolio Map**. - -### Market Opportunity Set Panel - -Contains market opportunity cards generated from: - -```text -application + customer = market opportunity -``` - -Each card should have: - -| Field | Description | -|---|---| -| ID | Short stable label such as MO-1, MO-2, MO-3 | -| Application | What the core ability enables | -| Customer segment | Who needs that application | -| Market opportunity | Combined application + customer | - -### Attractiveness Map Panel - -Axes: - -| Axis | Direction | Rating Levels | -|---|---|---| -| Potential | vertical | Low, Mid, High, Super High | -| Challenge | horizontal | Low, Mid, High, Super High | - -Zones: - -| Zone | Meaning | -|---|---| -| Gold Mine | High potential with relatively low challenge | -| Quick Win | Lower potential with relatively low challenge | -| Moon Shot | High potential with high challenge | -| Questionable | Lower potential with high challenge | - -### Focus Portfolio Map Panel - -Nested decision areas: - -| Area | Meaning | -|---|---| -| Pursue now | Active focus or active parallel pursuit | -| Keep open | Preserve option value without fully committing | -| Place in storage | Document but do not actively preserve now | - -Cards placed here must identify whether they are primary, backup, growth, or storage -options. - -## 2. Opportunity Set Builder - -Purpose: generate market opportunities by combining core abilities, applications, and -customer segments. - -Required fields: - -- Name. -- Date. -- Title: `Generate Your Market Opportunity Set`. -- Core abilities or technological elements. -- Applications. -- Customers. -- Market opportunities. - -### Core Abilities Table - -List the venture's core abilities or technological elements. Characterize each by -function and properties, independent from the envisioned product. - -| Ability ID | Core Ability or Technological Element | Function | Key Properties | Evidence / Notes | -|---|---|---|---|---| -| A1 | | | | | -| A2 | | | | | -| A3 | | | | | -| A4 | | | | | - -### Market Opportunity Generation Table - -Use each row to combine an application with a customer segment. - -| Opportunity ID | Ability ID(s) | Application | Customer Segment | Finer Customer Segmentation | Market Opportunity | -|---|---|---|---|---|---| -| MO-1 | | | | | | -| MO-2 | | | | | | -| MO-3 | | | | | | - -Generation prompts: - -- Which applications can the core abilities offer? -- Which customers may need each application? -- Can the customer group be segmented more precisely? -- Which combinations should be evaluated next? - -## 3. Attractiveness Evaluator - -Purpose: evaluate each market opportunity by potential and challenge, then place it -on the attractiveness map. - -Required fields: - -- Name. -- Date. -- Title: `Evaluate Market Opportunity Attractiveness`. -- Market Opportunity. -- Potential. -- Challenge. -- Overall Potential. -- Overall Challenge. -- Attractiveness Map zone. - -Use this canvas once for every market opportunity being evaluated. - -### Potential Ratings - -| Potential Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Compelling Reason to Buy | Unmet need; effective solution; better than current solutions | Low / Mid / High / Super High | | -| Market Volume | Current market size; expected growth | Low / Mid / High / Super High | | -| Economic Viability | Margins (value vs. cost); customers' ability to pay; customer stickiness | Low / Mid / High / Super High | | - -### Challenge Ratings - -| Challenge Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Implementation Obstacles | Product development difficulties; sales and distribution difficulties; funding challenges | Low / Mid / High / Super High | | -| Time to Revenue | Development time; time between product and market readiness; length of sales cycle | Low / Mid / High / Super High | | -| External Risks | Competitive threat; third-party dependencies; barriers to adoption | Low / Mid / High / Super High | | - -### Overall Placement - -| Market Opportunity | Overall Potential | Overall Challenge | Map Zone | Rationale | -|---|---|---|---|---| -| | Low / Mid / High / Super High | Low / Mid / High / Super High | Gold Mine / Quick Win / Moon Shot / Questionable | | - -## 4. Focus Portfolio Planner - -Purpose: design the focus strategy around one primary market opportunity while -preserving backup and growth options. - -Required fields: - -- Name. -- Date. -- Title: `Design Your Focus Strategy`. -- Primary Market Opportunity. -- Other attractive market opportunities. -- Product relatedness. -- Market relatedness. -- Suitable as backup option. -- Suitable as growth option. -- Action decision: pursue now, keep open, or place in storage. - -### Step I: Choose Primary Market Opportunity - -Choose the primary market opportunity based on the attractiveness map. - -| Primary Market Opportunity | Attractiveness Map Position | Why This Is Primary | Main Evidence | Main Risks | -|---|---|---|---|---| -| | | | | | - -### Step II: Examine Other Attractive Opportunities - -For each other attractive market opportunity, compare it with the primary opportunity. - -| Option ID | Market Opportunity | Product Relatedness | Product Relatedness Rationale | Market Relatedness | Market Relatedness Rationale | Risk Overlap With Primary | -|---|---|---|---|---|---|---| -| MO-2 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-3 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-4 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | - -Product relatedness asks how much the products share: - -- Technological competences. -- Required resources. -- Necessary networks. - -Market relatedness asks how much the customers share: - -- Values and benefits. -- Sales channels. -- Word-of-mouth paths. - -### Step III: Classify and Decide - -Use this table to mark whether each option is suitable as backup, growth, both, or -neither, then decide what to do with it. - -| Option ID | Market Opportunity | Backup Option? | Growth Option? | Action | Rationale | -|---|---|---|---|---|---| -| MO-2 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-3 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-4 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | - -Definitions: - -- **Backup Option**: an attractive market opportunity that does not share major risks - with the primary market opportunity and can support a change in direction. -- **Growth Option**: an attractive market opportunity that can create additional value - if the primary opportunity succeeds. - -Strategy rule: - -- Keep at least one Backup Option open. -- Keep at least one Growth Option open. -- Decide whether any option is worth pursuing now. -- Place the rest in storage. - -### Final Focus Strategy Summary - -| Category | Market Opportunity | Decision | Why | -|---|---|---|---| -| Primary | | Pursue now | | -| Backup | | Keep open / Pursue now | | -| Growth | | Keep open / Pursue now | | -| Storage | | Place in storage | | diff --git a/plugins/productize-all/skills/productize-market-opportunity/references/output-formats.md b/plugins/productize-all/skills/productize-market-opportunity/references/output-formats.md deleted file mode 100644 index ee145a61..00000000 --- a/plugins/productize-all/skills/productize-market-opportunity/references/output-formats.md +++ /dev/null @@ -1,143 +0,0 @@ -# Output Formats - -Use the same canonical four-artifact structure in every format. Use neutral artifact -names in titles and headings. - -## Markdown Blank Canvas Set - -Use when the user wants editable text tables. - -Required sections: - -```markdown -# Market Opportunity - -## 1. Opportunity Overview Canvas -[overview tables] - -## 2. Opportunity Set Builder -[blank abilities and opportunity generation tables] - -## 3. Attractiveness Evaluator -[one blank evaluator per opportunity, or reusable blank evaluator] - -## 4. Focus Portfolio Planner -[blank primary, relatedness, backup/growth, and action decision tables] -``` - -## Markdown Filled Canvas Set - -Use when the user provides a venture, technology, product, or opportunity set. - -Required sections: - -```markdown -# Market Opportunity: [Venture/Product] - -## 1. Opportunity Overview Canvas -- Market opportunity cards. -- Attractiveness placements. -- Focus portfolio decisions. - -## 2. Opportunity Set Builder -- Core abilities. -- Applications. -- Customer segments. -- Generated market opportunities. - -## 3. Attractiveness Evaluator -- One evaluation table per selected market opportunity. -- Overall potential, overall challenge, and map zone. - -## 4. Focus Portfolio Planner -- Primary market opportunity. -- Option comparison by product and market relatedness. -- Backup/growth classification. -- Pursue now / keep open / place in storage decisions. - -## Strategy Implications -- Product/technology modularity. -- IP and defensibility. -- Hiring/capability needs. -- Stakeholder and investor alignment. -- Brand and communication implications. -- Experiments and next evidence to collect. -``` - -## Visual or Printable Canvas - -Use when the user asks for printable templates, visual canvases, an HTML file, a PDF, -or a slide-ready output. - -Requirements: - -- Produce four separate pages or sections. -- Preserve the same layout logic: - - Overview: three panels side by side. - - Opportunity Set Builder: abilities at top; applications and customers below. - - Attractiveness Evaluator: potential on left, challenge on right, overall ratings at - the bottom. - - Focus Portfolio Planner: primary opportunity at top, option columns below, relatedness - rows, backup/growth rows, action rows at bottom. -- Use neutral artifact titles. -- Include `Name` and `Date` fields when producing a printable artifact. -- Include editable blank spaces or filled content depending on the requested mode. - -Recommended visual names: - -| Original Function | Use This Title | -|---|---| -| Full opportunity overview | Market Opportunity Overview | -| Generate opportunity set | Opportunity Set Builder | -| Evaluate attractiveness | Market Opportunity Attractiveness | -| Design focus strategy | Focus Strategy Planner | - -## Compact Decision Memo - -Use when the user wants a concise strategic answer rather than the full canvas set. - -Required sections: - -```markdown -## Recommendation -[Primary market opportunity and why] - -## Opportunity Portfolio -| Category | Opportunity | Decision | Why | - -## Key Ratings -| Opportunity | Potential | Challenge | Zone | - -## Risks and Open Assumptions -[Most important evidence gaps] - -## Next Tests -[Lean experiments or research needed] -``` - -## Spreadsheet-Friendly Format - -Use when the user wants to paste into Sheets/Excel. - -Create four CSV-style tables: - -1. `opportunity_set` -2. `attractiveness_ratings` -3. `map_placements` -4. `focus_portfolio` - -Minimum columns: - -```text -opportunity_set: -opportunity_id,ability_ids,application,customer_segment,finer_segment,market_opportunity - -attractiveness_ratings: -opportunity_id,potential_compelling_reason,potential_market_volume,potential_economic_viability,overall_potential,challenge_implementation,challenge_time_to_revenue,challenge_external_risks,overall_challenge,evidence_notes - -map_placements: -opportunity_id,overall_potential,overall_challenge,map_zone - -focus_portfolio: -opportunity_id,role,product_relatedness,market_relatedness,risk_overlap,backup_option,growth_option,action,rationale -``` diff --git a/plugins/productize-all/skills/productize-market-opportunity/references/rating-and-decision-rules.md b/plugins/productize-all/skills/productize-market-opportunity/references/rating-and-decision-rules.md deleted file mode 100644 index fdfe3093..00000000 --- a/plugins/productize-all/skills/productize-market-opportunity/references/rating-and-decision-rules.md +++ /dev/null @@ -1,250 +0,0 @@ -# Rating and Decision Rules - -Use these rules to keep opportunity ratings consistent. - -## Rating Scale - -Use only these four levels: - -```text -Low / Mid / High / Super High -``` - -For challenge dimensions, higher means more difficult, slower, riskier, or more -resource-intensive. Low challenge is good. - -## Potential Ratings - -### Compelling Reason to Buy - -Rate based on: - -- Strength of unmet need. -- Whether the solution effectively addresses the need. -- Whether it is better than current alternatives. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak pain, unclear need, or little advantage over alternatives | -| Mid | Recognizable need but limited urgency or differentiation | -| High | Clear need, strong solution fit, meaningful advantage | -| Super High | Urgent need, strong willingness to switch or buy, clear superiority | - -### Market Volume - -Rate based on: - -- Current market size. -- Expected growth. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Small or shrinking reachable market | -| Mid | Meaningful niche or uncertain growth | -| High | Large reachable market or strong growth | -| Super High | Very large market with strong growth and credible reach | - -### Economic Viability - -Rate based on: - -- Margins: value created versus cost to deliver. -- Customers' ability to pay. -- Customer stickiness. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak margins, low willingness or ability to pay, low retention potential | -| Mid | Economics may work but are not yet proven | -| High | Attractive value/cost relationship and credible willingness to pay | -| Super High | Strong margins, high willingness to pay, strong retention or lock-in | - -## Challenge Ratings - -### Implementation Obstacles - -Rate based on: - -- Product development difficulties. -- Sales and distribution difficulties. -- Funding challenges. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Straightforward product, go-to-market, and funding path | -| Mid | Some execution difficulty, but manageable | -| High | Significant product, distribution, or funding obstacles | -| Super High | Very difficult execution path or major resource gap | - -### Time to Revenue - -Rate based on: - -- Development time. -- Gap between product readiness and market readiness. -- Length of sales cycle. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Revenue can plausibly arrive quickly | -| Mid | Moderate path to revenue | -| High | Long development, readiness, or sales cycle | -| Super High | Very long or uncertain time to revenue | - -### External Risks - -Rate based on: - -- Competitive threat. -- Third-party dependencies. -- Barriers to adoption. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Limited external risk or manageable dependencies | -| Mid | Some competitive, dependency, or adoption risk | -| High | Serious external risks that could block progress | -| Super High | External risks may dominate the opportunity | - -## Overall Potential and Challenge - -Do not compute mechanically unless the user asks for numeric scoring. Use evidence and -judgment. - -Default aggregation: - -- Overall Potential should reflect the weakest critical potential dimension. A huge - market is not enough if there is no compelling reason to buy. -- Overall Challenge should reflect the hardest blocking challenge. A simple build is - not enough if revenue requires a multi-year sales cycle. - -If using numeric support: - -```text -Low = 1 -Mid = 2 -High = 3 -Super High = 4 -``` - -Use the rounded average as a starting point, then adjust for blockers and explain the -adjustment. - -## Attractiveness Map Zone Rules - -| Overall Potential | Overall Challenge | Zone | -|---|---|---| -| High or Super High | Low or Mid | Gold Mine | -| Low or Mid | Low or Mid | Quick Win | -| High or Super High | High or Super High | Moon Shot | -| Low or Mid | High or Super High | Questionable | - -Interpretation: - -- **Gold Mine**: strongest candidate for primary focus. -- **Quick Win**: potentially useful for learning, early traction, or stepping stones. -- **Moon Shot**: valuable but difficult; may require capital, patience, or unique assets. -- **Questionable**: weak candidate unless strategic reasons or new evidence change the view. - -## Primary Market Opportunity Rules - -Select the primary opportunity by weighing: - -- Attractiveness map zone. -- Strength of evidence. -- Founder/team fit. -- Ability to test assumptions. -- Strategic control and defensibility. -- Fit with resource constraints. - -Default preference: - -1. Gold Mine with strong evidence. -2. Gold Mine with evidence gaps but testable assumptions. -3. Quick Win if it creates learning, revenue, or capability for a larger path. -4. Moon Shot only if the upside is large enough and the team has unusual advantages. -5. Questionable only if the user explicitly has strategic reasons. - -## Backup Option Rules - -A backup option should be attractive and should not share major risks with the primary -opportunity. - -Good backup options often differ on: - -- Customer segment. -- Sales channel. -- Adoption barrier. -- Regulatory pathway. -- Revenue model. -- Critical dependency. - -Do not label an option as backup merely because it is related. If it fails for the same -reason the primary fails, it is not a useful backup. - -## Growth Option Rules - -A growth option should be attractive and should let the venture create additional value -after or alongside the primary opportunity. - -Good growth options often share: - -- Technology. -- Capabilities. -- Customer relationships. -- Distribution. -- Brand credibility. -- Data or network effects. - -High relatedness makes a growth option more plausible. Very low relatedness usually -means the opportunity is diversification, not a near-term growth option. - -## Action Decision Rules - -### Pursue Now - -Use when: - -- The option is primary, or -- The option is highly attractive, resources permit parallel pursuit, and pursuing it - does not dilute the primary focus. - -### Keep Open - -Use when: - -- The option has strategic value as backup or growth. -- The cost of preserving it is modest. -- It requires monitoring, lightweight experiments, modular design choices, IP claims, - partner conversations, or relationship maintenance. - -### Place in Storage - -Use when: - -- The option is not attractive enough now. -- The opportunity is too unrelated or costly to preserve. -- Evidence is too weak. -- It is worth remembering but not worth spending active effort on. - -## Evidence Discipline - -For each rating, distinguish: - -- Evidence: facts, interviews, data, observed behavior, signed interest, market numbers. -- Assumptions: plausible but unvalidated beliefs. -- Unknowns: missing information that could change the rating. - -When evidence is weak, phrase the output as a hypothesis and propose the next test. diff --git a/plugins/productize-all/skills/productize-market-orientation-audit/SKILL.md b/plugins/productize-all/skills/productize-market-orientation-audit/SKILL.md deleted file mode 100644 index 914f16eb..00000000 --- a/plugins/productize-all/skills/productize-market-orientation-audit/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: productize-market-orientation-audit -description: >- - Audit whether an organization is truly market oriented using intelligence generation, - intelligence dissemination, and responsiveness. Use for customer-centricity, marketing - culture, organizational diagnosis, market sensing, and scorecard-based improvement plans. ---- - - - -# Market Orientation Audit - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-orientation-audit` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user wants to diagnose how well an organization senses markets, shares customer/competitor insight internally, and acts on that insight. - -Do not use it for brand health, campaign evaluation, or product-market fit unless the question is specifically about organizational market orientation. - -## Core Model - -Market orientation is an organization-wide culture and operating system for creating customer value. It has three dimensions: - -- **Intelligence generation**: how the organization detects customer, competitor, collaborator, technology, and regulatory changes. -- **Intelligence dissemination**: how quickly and effectively insight spreads across functions. -- **Responsiveness**: how fast and well the organization acts on market intelligence. - -## Scorecard - -Use a 1-5 scale: - -- 5 = Strongly agree -- 4 = Agree -- 3 = Neither agree nor disagree -- 2 = Disagree -- 1 = Strongly disagree - -Each dimension has 8 items. Dimension scoring: - -- 29-40 = High -- 20-28 = Moderate -- 8-19 = Low - -Total scoring: - -- 86-120 = High -- 60-85 = Moderate -- 24-59 = Low - -### Intelligence Generation - -1. We have interdepartmental meetings at least once a quarter to discuss market trends and developments. -2. We are quick to detect fundamental shifts in our industry, such as competition, technology, or regulation. -3. We periodically review the likely effect of environmental changes on customers. -4. We are fast to detect changes in customer product and service preferences. -5. People discuss customers' future needs with other functions or departments. -6. We do a lot of in-house market research. -7. We survey key customers at least once a year to assess product and service quality. -8. We meet key clients at least once a year to learn what products or services they will need in the future. - -### Intelligence Dissemination - -1. When something important happens to a major customer or market, the whole business knows quickly. -2. When one department learns something important about competitors, it quickly alerts other departments. -3. We would never ignore changes in customer product or service needs. -4. When customers want a product or service modification, involved teams make concerted efforts to respond. -5. We periodically review product or service development to ensure it aligns with key customer needs. -6. We have communication systems that speed dissemination of important customer-related information. -7. All functions and departments are responsive to each other's needs and requests. -8. When a customer complains or gives feedback, we quickly share it with anyone who can act on it. - -### Responsiveness - -1. It takes very little time to decide how to respond to competitor product or service changes. -2. We can implement new ideas, marketing plans, product redesigns, or service enhancements in a timely fashion. -3. Several functions periodically plan responses to changes in the business environment. -4. If a major competitor aggressively targeted a key customer, we would consider a response immediately. -5. We quickly act on customer complaints and feedback. -6. Customer-facing employees have latitude to solve customer problems without excessive red tape. -7. People here tend to talk more about opportunities than problems. -8. When we see a new opportunity to create customer value, we act quickly. - -## Workflow - -1. Collect scores from the user or run a facilitated self-assessment. -2. Compute dimension totals and total score. -3. Identify the weakest dimension and the lowest individual items. -4. Diagnose root causes across incentives, structure, tooling, decision rights, data access, rituals, and culture. -5. Translate findings into operating changes, not just research recommendations. -6. Define a 30/60/90-day improvement plan and measurement cadence. - -## Output - -Return: - -- **Score Summary**: dimension scores, total score, high/moderate/low rating. -- **Pattern Diagnosis**: what the scores imply about market sensing, sharing, and action. -- **Lowest Items**: the specific behaviors causing the largest gap. -- **Organizational Hurdles**: structure, incentives, data, rituals, authority, culture. -- **Improvement Plan**: 30/60/90-day actions. -- **Operating Metrics**: indicators to track improvement. - -## Quality Bar - -- Do not equate customer-facing friendliness with market orientation. -- Treat market orientation as cross-functional. -- Separate collecting insight from acting on insight. -- Recommend concrete operating changes, not generic "talk to customers more" advice. diff --git a/plugins/productize-all/skills/productize-market-orientation-audit/agents/openai.yaml b/plugins/productize-all/skills/productize-market-orientation-audit/agents/openai.yaml deleted file mode 100644 index 0f9e2a0d..00000000 --- a/plugins/productize-all/skills/productize-market-orientation-audit/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market Orientation Audit" - short_description: "Audit whether an organization is truly market oriented using intelligence generation, intelligence dissemination,..." - brand_color: "#EA580C" - default_prompt: "Use $productize-market-orientation-audit with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md b/plugins/productize-all/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md deleted file mode 100644 index ca888dbb..00000000 --- a/plugins/productize-all/skills/productize-market-requirements-from-strategic-market-inputs/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: productize-market-requirements-from-strategic-market-inputs -description: >- - Market requirements from strategic market inputs. Use when the user needs a product workflow - for product strategy related to market requirements from strategic market inputs. Trigger - terms: product-management, market-research, strategy, MRD. ---- - - - -# Market requirements from strategic market inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-requirements-from-strategic-market-inputs` -- **Lifecycle**: Strategize -- **Category**: Discovery -- **Primary artifact**: Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Market requirements from strategic market inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MARKET_INDUSTRY}} -- {{PROBLEM_UNMET_NEED}} -- {{TARGET_USER_BUYER}} -- {{CURRENT_ALTERNATIVES}} -- {{COMPANY_ROLE_VISION_ADVANTAGE}} -- {{EXTERNAL_FACTORS}} -- {{OUTPUT_REQUEST}} - - -GOAL -Produce a high-quality deliverable for: Market requirements from strategic market inputs. -Success metric: -- Gathers required MRD inputs via a structured question flow. -- Produces decision-ready MRD sections only after the user confirms โ€œReady to draft.โ€ -- Keeps analysis concise, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; ask one question at a time until the user says **โ€œReady to draft.โ€** -- Do not draft any MRD section before the user explicitly says **โ€œReady to draft.โ€** -- After the user selects the output (Aโ€“D), produce that section only and pause for feedback. -- Use links for citations; state assumptions explicitly. -- No emojis. No JSON output. - -FORMAT -Return exactly this structure: - - -Letโ€™s co-create a Market Requirements Document. Iโ€™ll ask a few questions to gather context and then generate a draft. First up: What market or industry are you exploring? - - - -[Your single next question based on the most recent answer] - - -[When user says โ€œReady to draft,โ€ respond with exactly one of the requested MRD sections using the MRD Output Format headings.] - -FAILURE -- Output drafts MRD sections before user says โ€œReady to draft.โ€ -- More than one question is asked at a time. -- Output does not follow the selected section from Aโ€“D. -- Missing citations/assumptions where needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-market-requirements-from-strategic-market-inputs/agents/openai.yaml b/plugins/productize-all/skills/productize-market-requirements-from-strategic-market-inputs/agents/openai.yaml deleted file mode 100644 index f3445b63..00000000 --- a/plugins/productize-all/skills/productize-market-requirements-from-strategic-market-inputs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market requirements from strategic market inputs" - short_description: "Market requirements from strategic market inputs. Use when the user needs a product workflow for product strategy..." - brand_color: "#0D9488" - default_prompt: "Use $productize-market-requirements-from-strategic-market-inputs with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-market-sizing/SKILL.md b/plugins/productize-all/skills/productize-market-sizing/SKILL.md deleted file mode 100644 index 6467fec0..00000000 --- a/plugins/productize-all/skills/productize-market-sizing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, - market-entry upside, or investor-ready opportunity size. ---- - - - -# Market Sizing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-sizing` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/plugins/productize-all/skills/productize-market-sizing/agents/openai.yaml b/plugins/productize-all/skills/productize-market-sizing/agents/openai.yaml deleted file mode 100644 index 39b8d438..00000000 --- a/plugins/productize-all/skills/productize-market-sizing/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market Sizing" - short_description: "Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or..." - brand_color: "#0F766E" - default_prompt: "Use $productize-market-sizing with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md b/plugins/productize-all/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md deleted file mode 100644 index be955241..00000000 --- a/plugins/productize-all/skills/productize-mece-analysis-and-logical-tree-from-list-items/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: productize-mece-analysis-and-logical-tree-from-list-items -description: >- - MECE analysis and logical tree from list items. Use when the user needs a product workflow - for decision making related to mece analysis and logical tree from list items. Trigger - terms: pm, decision-making, mece, structured-thinking, frameworks. ---- - - - -# MECE analysis and logical tree from list items - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `mece-analysis-and-logical-tree-from-list-items` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **MECE analysis and logical tree from list items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{LIST_OF_ITEMS}} - - -GOAL -Evaluate `LIST_OF_ITEMS` for MECE quality and produce a logical tree that resolves overlaps/gaps. -Success metric: -- Clearly assesses mutual exclusivity and collective exhaustiveness. -- Identifies concrete overlaps and coverage gaps (if any). -- Produces a coherent tree structure reflecting corrected grouping logic. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Test pairwise overlap (mutual exclusivity). - 2. Test coverage gaps (collective exhaustiveness). - 3. Propose corrected structure and hierarchy. -- Keep conclusions grounded in the provided list; avoid unrelated frameworks unless necessary. -- If ambiguity exists in item definitions, state assumptions explicitly. -- Provide concise rationale, not hidden/internal chain-of-thought. - -FORMAT -Return exactly this structure: - - - -[State whether items are mutually exclusive, with specific overlap examples where relevant] - - -[State whether items are collectively exhaustive, with specific gap examples where relevant] - - -[Concise list of overlap issues and/or coverage gaps] - - - - -[MECE status: Fully MECE | Not MECE | Partially MECE] - -[Hierarchical tree showing corrected structure and item placement] - - - -FAILURE -- Required schema sections are missing or malformed. -- Mutual exclusivity or collective exhaustiveness assessment is absent. -- Logical tree is missing, unclear, or inconsistent with analysis findings. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-mece-analysis-and-logical-tree-from-list-items/agents/openai.yaml b/plugins/productize-all/skills/productize-mece-analysis-and-logical-tree-from-list-items/agents/openai.yaml deleted file mode 100644 index f668648b..00000000 --- a/plugins/productize-all/skills/productize-mece-analysis-and-logical-tree-from-list-items/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "MECE analysis and logical tree from list items" - short_description: "MECE analysis and logical tree from list items. Use when the user needs a product workflow for decision making..." - brand_color: "#059669" - default_prompt: "Use $productize-mece-analysis-and-logical-tree-from-list-items with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md b/plugins/productize-all/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md deleted file mode 100644 index 917e0acf..00000000 --- a/plugins/productize-all/skills/productize-meeting-agendas-from-meeting-descriptions/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: productize-meeting-agendas-from-meeting-descriptions -description: >- - Meeting agendas from meeting descriptions. Use when the user needs a product workflow for - project management related to meeting agendas from meeting descriptions. Trigger terms: - meetings, facilitation, planning, productivity. ---- - - - -# Meeting agendas from meeting descriptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-agendas-from-meeting-descriptions` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Meeting agendas from meeting descriptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DESCRIPTION}} - - -GOAL -Produce a high-quality deliverable for: "Meeting agendas from meeting descriptions". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a meeting preparation output from `{{MEETING_DESCRIPTION}}` that includes: -- A clear purpose statement for the meeting. -- A structured agenda with allocated time per topic and key questions per topic. -- A practical process/flow for running the meeting to achieve the stated purpose. -- Internally reason from meeting goals, stakeholders, and constraints; return only the required final sections. - -FORMAT -Return exactly this structure: - - -[Clear and concise purpose statement] - - - -1. [Agenda Topic 1] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -2. [Agenda Topic 2] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -[Additional agenda topics] - - - -[Suggested process and flow for the meeting] - - -FAILURE -- Any required section (``, ``, ``) is missing or materially incomplete. -- Agenda items do not include both time allocation and key questions. -- Meeting flow/process is generic and not tied to the stated purpose. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-meeting-agendas-from-meeting-descriptions/agents/openai.yaml b/plugins/productize-all/skills/productize-meeting-agendas-from-meeting-descriptions/agents/openai.yaml deleted file mode 100644 index 5b03e046..00000000 --- a/plugins/productize-all/skills/productize-meeting-agendas-from-meeting-descriptions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Meeting agendas from meeting descriptions" - short_description: "Meeting agendas from meeting descriptions. Use when the user needs a product workflow for project management related..." - brand_color: "#7C3AED" - default_prompt: "Use $productize-meeting-agendas-from-meeting-descriptions with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md b/plugins/productize-all/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md deleted file mode 100644 index bbf05acf..00000000 --- a/plugins/productize-all/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: productize-meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- - - - -# Meeting Outcome Planning and Stakeholder Alignment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-outcome-planning-and-stakeholder-alignment` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/agents/openai.yaml b/plugins/productize-all/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/agents/openai.yaml deleted file mode 100644 index 3ad782ad..00000000 --- a/plugins/productize-all/skills/productize-meeting-outcome-planning-and-stakeholder-alignment/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Meeting Outcome Planning and Stakeholder Alignment" - short_description: "Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product workflow for stakeholder..." - brand_color: "#7C2D12" - default_prompt: "Use $productize-meeting-outcome-planning-and-stakeholder-alignment with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md b/plugins/productize-all/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md deleted file mode 100644 index 60997def..00000000 --- a/plugins/productize-all/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-meeting-summaries-from-meeting-transcript-ideas-framework -description: >- - Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a - product workflow for presentation & communication related to meeting summaries from meeting - transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, - note-taking. ---- - - - -# Meeting summaries from meeting transcript (IDEAS framework) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-summaries-from-meeting-transcript-ideas-framework` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Meeting summaries from meeting transcript (IDEAS framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Meeting summaries from meeting transcript (IDEAS framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are tasked with summarizing a meeting using the IDEAS framework. This framework helps organize the key points of a meeting into five categories: Insights, Decisions, Engagements, Actions, and Summary. Here's the meeting transcript you need to analyze: - - -{{MEETING_TRANSCRIPT}} - - -Please carefully read and analyze the meeting transcript. Then, summarize the meeting using the IDEAS framework as follows: - -1. Insights: Identify and list the main insights or important realizations that emerged during the meeting. -2. Decisions: Note any decisions that were made during the meeting. -3. Engagements: List any tasks or responsibilities that were assigned to specific individuals or teams. -4. Actions: Highlight any immediate actions that need to be taken as a result of the meeting. -5. Summary: Provide a brief overall summary of the meeting's impact and significance. - -When writing your summary, please be concise and focused. Aim to capture the most important points rather than trying to include every detail. Use bullet points for each category to make the summary easy to read and understand. - -Present your summary using the following format, enclosed in XML tags: - -Remember to focus on the most significant and relevant information for each category. Your goal is to provide a clear, organized, and useful summary of the meeting using the IDEAS framework. - - -FORMAT -Return exactly this structure: - - - -โ€ข [List insights here] - - - -โ€ข [List decisions here] - - - -โ€ข [List engagements here] - - - -โ€ข [List actions here] - - - -[Write a brief overall summary here] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/agents/openai.yaml b/plugins/productize-all/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/agents/openai.yaml deleted file mode 100644 index 32f48331..00000000 --- a/plugins/productize-all/skills/productize-meeting-summaries-from-meeting-transcript-ideas-framework/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Meeting summaries from meeting transcript (IDEAS framework)" - short_description: "Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a product workflow for..." - brand_color: "#7C3AED" - default_prompt: "Use $productize-meeting-summaries-from-meeting-transcript-ideas-framework with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-message-framing-and-comms-plan-designer/SKILL.md b/plugins/productize-all/skills/productize-message-framing-and-comms-plan-designer/SKILL.md deleted file mode 100644 index 8cc37534..00000000 --- a/plugins/productize-all/skills/productize-message-framing-and-comms-plan-designer/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: productize-message-framing-and-comms-plan-designer -description: >- - Message Framing & Comms Plan Designer. Use when the user needs a product workflow for - stakeholder management related to message framing & comms plan designer. Trigger terms: - communication, executive-communication, messaging, stakeholder-management. ---- - - - -# Message Framing & Comms Plan Designer - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `message-framing-and-comms-plan-designer` -- **Lifecycle**: Design -- **Category**: Marketing -- **Primary artifact**: Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Message Framing & Comms Plan Designer**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Message Framing & Comms Plan Designer. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use provided facts, audience, goal, and writing sample to design a message framing and communication plan. -- Provide 2-3 viable framing options, each with a one-line rationale tied to credibility, logic, and audience emotion. -- Produce two concise drafts in the user's natural tone: -- `ICs` draft with context, changes, actions, and timeline (`<=180` words). -- `Execs` draft with BLUF, risks/asks, and decision needed (`<=120` words). -- Include a strong subject/headline and two Slack snippets (announcement + reminder). -- Provide a mini comms plan with channel sequence, owner, timing, emphasis, and CTA. -- Include a `What to Omit` noise-reduction list and exactly 3 success signals. - -FORMAT -Return exactly this structure: - -Frames & Rationale -- [Frame 1]: [one-line rationale] -- [Frame 2]: [one-line rationale] -- [Frame 3 if used]: [one-line rationale] - -Draft for ICs -Subject/Headline: [text] -[ICs draft <=180 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Draft for Execs -Subject/Headline: [text] -[Execs draft <=120 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Mini Comms Plan -| Step | Channel | Owner | Timing | Emphasis | CTA | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -What to Omit -- [item] - -Success Signals -1. [signal] -2. [signal] -3. [signal] - -FAILURE -- Any required section is missing or materially incomplete. -- ICs draft exceeds 180 words or Execs draft exceeds 120 words. -- Missing subject/headline or missing either Slack snippet type (announcement/reminder). -- Comms plan table is missing required columns or sequence logic. -- Success Signals are not exactly three measurable indicators. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-all/skills/productize-message-framing-and-comms-plan-designer/agents/openai.yaml b/plugins/productize-all/skills/productize-message-framing-and-comms-plan-designer/agents/openai.yaml deleted file mode 100644 index 9d362596..00000000 --- a/plugins/productize-all/skills/productize-message-framing-and-comms-plan-designer/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Message Framing & Comms Plan Designer" - short_description: "Message Framing & Comms Plan Designer. Use when the user needs a product workflow for stakeholder management related..." - brand_color: "#EA580C" - default_prompt: "Use $productize-message-framing-and-comms-plan-designer with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md b/plugins/productize-all/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md deleted file mode 100644 index 364641cd..00000000 --- a/plugins/productize-all/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- - - - -# Metric drops diagnosis with rigorous stepwise decomposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- **Lifecycle**: Strategize -- **Category**: Analytics -- **Primary artifact**: Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/plugins/productize-all/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml b/plugins/productize-all/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml deleted file mode 100644 index 7ed9dec0..00000000 --- a/plugins/productize-all/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Metric drops diagnosis with rigorous stepwise decomposition" - short_description: "Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a product workflow for business..." - brand_color: "#0F766E" - default_prompt: "Use $productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition with my product context." - -policy: - allow_implicit_invocation: false diff --git a/plugins/productize-all/skills/productize-metrics-review/SKILL.md b/plugins/productize-all/skills/productize-metrics-review/SKILL.md deleted file mode 100644 index ce1527cf..00000000 --- a/plugins/productize-all/skills/productize-metrics-review/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-metrics-review -description: >- - Review and analyze product metrics with trend analysis and actionable insights. Use when - running a weekly, monthly, or quarterly metrics review, investigating a spike or drop, - comparing against targets, or turning raw numbers into a scorecard with recommended actions. ---- - - - -# Metrics Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metrics-review` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Metric scorecard, trend diagnosis, and recommended action plan - -Review product metrics, identify trends, and surface action-oriented insights. - -## Argument Hint - -`
` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/plugins/productize-analytics/skills/productize-explore-data/agents/openai.yaml b/plugins/productize-analytics/skills/productize-explore-data/agents/openai.yaml deleted file mode 100644 index 9d370170..00000000 --- a/plugins/productize-analytics/skills/productize-explore-data/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Explore Data" - short_description: "Profile and explore a dataset to understand its shape, quality, and patterns. Use when encountering a new table or..." - brand_color: "#0F766E" - default_prompt: "Use $productize-explore-data with my product context." - -policy: - allow_implicit_invocation: true diff --git a/plugins/productize-analytics/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md b/plugins/productize-analytics/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md deleted file mode 100644 index ba3f5a3b..00000000 --- a/plugins/productize-analytics/skills/productize-feature-results-analysis-from-draft-to-final-report/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: productize-feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- - - - -# Feature results analysis from draft to final report - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-results-analysis-from-draft-to-final-report` -- **Lifecycle**: Launch & Learn -- **Category**: Analytics -- **Primary artifact**: Feature results readout with iterate, rollback, kill, or scale recommendation - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/plugins/productize-analytics/skills/productize-feature-results-analysis-from-draft-to-final-report/agents/openai.yaml b/plugins/productize-analytics/skills/productize-feature-results-analysis-from-draft-to-final-report/agents/openai.yaml deleted file mode 100644 index a255f44c..00000000 --- a/plugins/productize-analytics/skills/productize-feature-results-analysis-from-draft-to-final-report/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Feature results analysis from draft to final report" - short_description: "Feature results analysis from draft to final report. Use when the user needs a product workflow for business..." - brand_color: "#0F766E" - default_prompt: "Use $productize-feature-results-analysis-from-draft-to-final-report with my product context." - -policy: - allow_implicit_invocation: true diff --git a/plugins/productize-analytics/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md b/plugins/productize-analytics/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md deleted file mode 100644 index 364641cd..00000000 --- a/plugins/productize-analytics/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- - - - -# Metric drops diagnosis with rigorous stepwise decomposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- **Lifecycle**: Strategize -- **Category**: Analytics -- **Primary artifact**: Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/plugins/productize-analytics/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml b/plugins/productize-analytics/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml deleted file mode 100644 index 19f6d9bc..00000000 --- a/plugins/productize-analytics/skills/productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Metric drops diagnosis with rigorous stepwise decomposition" - short_description: "Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a product workflow for business..." - brand_color: "#0F766E" - default_prompt: "Use $productize-metric-drops-diagnosis-with-rigorous-stepwise-decomposition with my product context." - -policy: - allow_implicit_invocation: true diff --git a/plugins/productize-analytics/skills/productize-metrics-review/SKILL.md b/plugins/productize-analytics/skills/productize-metrics-review/SKILL.md deleted file mode 100644 index ce1527cf..00000000 --- a/plugins/productize-analytics/skills/productize-metrics-review/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: productize-metrics-review -description: >- - Review and analyze product metrics with trend analysis and actionable insights. Use when - running a weekly, monthly, or quarterly metrics review, investigating a spike or drop, - comparing against targets, or turning raw numbers into a scorecard with recommended actions. ---- - - - -# Metrics Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metrics-review` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Metric scorecard, trend diagnosis, and recommended action plan - -Review product metrics, identify trends, and surface action-oriented insights. - -## Argument Hint - -`
` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/skills/explore-data/SKILL.md.tmpl b/skills/explore-data/SKILL.md.tmpl deleted file mode 100644 index 22ca00f6..00000000 --- a/skills/explore-data/SKILL.md.tmpl +++ /dev/null @@ -1,218 +0,0 @@ ---- -name: explore-data -description: >- - Profile and explore a dataset to understand its shape, quality, and patterns. Use when - encountering a new table or file, checking null rates and distributions, spotting duplicates or - suspicious values, or deciding which dimensions and metrics to analyze. ---- -# Explore Data - -{{PRODUCTIZE_PREAMBLE}} - -Generate a comprehensive data profile for a table or file before deeper analysis. - -## Argument Hint - -`
` - -## Usage - -```text -/explore-data -``` - -## Workflow - -### 1. Access Data - -If a data warehouse or analytics MCP is connected: -1. Resolve the table name, including schema prefixes. -2. Query table metadata: columns, types, descriptions, size, update metadata if available. -3. Run profiling queries against live data. Use sampling for very large tables and disclose it. - -If a file is provided: -1. Load CSV, Excel, Parquet, or JSON into a working dataset. -2. Infer column types and normalize obvious parsing issues. - -If neither is available, ask for a table name, file, pasted sample, or schema description. If only a schema is provided, give profiling SQL the user can run. - -### 2. Understand Structure - -Answer table-level questions: -- Rows and columns. -- Grain: one row per what. -- Primary key or natural key, and whether it is unique. -- Last updated timestamp and expected refresh cadence if known. -- Date coverage and earliest/latest records. - -Classify columns: -- Identifier: primary keys, foreign keys, entity IDs. -- Dimension: categorical attributes for grouping/filtering. -- Metric: quantitative values. -- Temporal: dates and timestamps. -- Text: free-form strings. -- Boolean: true/false flags. -- Structural: JSON, arrays, nested data. - -### 3. Profile Columns - -Table-level: -- Total row count. -- Column count and type breakdown. -- Approximate table size if available. -- Date range for temporal columns. - -All columns: -- Null count and null rate. -- Distinct count and cardinality ratio. -- Top 5-10 most common values with frequencies. -- Rare values when useful for anomaly detection. - -Numeric columns: -- Min, max, mean, median, standard deviation. -- Percentiles: p1, p5, p25, p75, p95, p99. -- Zero count and negative count. -- Distribution shape and outliers. - -String columns: -- Min, max, and average length. -- Empty string count. -- Pattern consistency. -- Case consistency. -- Leading/trailing whitespace. - -Temporal columns: -- Min and max dates. -- Null and future dates. -- Distribution by month/week. -- Time series gaps. - -Boolean columns: -- True count, false count, null count, true rate. - -### 4. Flag Data Quality Issues - -Use severity labels: high, medium, low. - -Flag: -- High null rates: warn above 5 percent, alert above 20 percent. -- Duplicate natural keys. -- Low-cardinality IDs or unexpectedly high-cardinality categorical fields. -- Suspicious values: negative amounts, future dates, placeholders, test values, impossible ranges. -- Skewed distributions that make averages misleading. -- Encoding and formatting issues: mixed case, whitespace, inconsistent formats. -- Cross-column rule violations: completed status with missing completed_at, end date before start date. -- Staleness or unexpected load lag. - -### 5. Discover Patterns - -Look for: -- Foreign key candidates. -- Natural hierarchies such as country -> state -> city. -- Numeric correlations worth investigating. -- Derived columns that appear calculated from other fields. -- Redundant or near-identical columns. -- Natural segments based on categorical fields with useful cardinality. - -### 6. Recommend What To Analyze Next - -Suggest: -- Best dimensions for slicing data. -- Key metric columns. -- Time columns suitable for trends. -- Natural groupings or hierarchies. -- Potential join keys. -- 3-5 concrete follow-up analyses. - -Examples: -- Trend analysis on `[metric]` by `[time_column]` grouped by `[dimension]`. -- Distribution deep dive on `[skewed_column]`. -- Data quality investigation on `[problematic_column]`. -- Correlation analysis between `[metric_a]` and `[metric_b]`. -- Cohort analysis using `[date_column]` and `[status_column]`. - -## Output Format - -```markdown -## Data Profile: [table_or_file] - -### Overview -- Rows: -- Columns: -- Grain: -- Primary key: -- Date range: -- Last updated: - -### Column Details -[Summary table grouped by IDs, dimensions, metrics, dates, booleans, text, structural fields] - -### Data Quality Issues -[Severity, field, issue, evidence, recommendation] - -### Patterns and Relationships -[Join keys, hierarchies, correlations, derived/redundant fields] - -### Recommended Explorations -[Numbered list of follow-up analyses] -``` - -## Quality Framework - -Completeness: -- Complete: more than 99 percent non-null. -- Mostly complete: 95-99 percent. -- Incomplete: 80-95 percent. -- Sparse: below 80 percent. - -Consistency checks: -- Same concept represented multiple ways. -- Numbers stored as strings. -- Dates in inconsistent formats. -- Foreign keys without parents. -- Business rule violations. - -Accuracy red flags: -- Placeholder values such as 0, -1, 999999, N/A, TBD, test, xxx. -- Suspicious default values. -- Stale active-system data. -- Impossible values. -- Round-number bias. - -Timeliness: -- Last updated time. -- Expected update frequency. -- Event-to-load lag. -- Gaps in expected time series. - -## Schema Documentation Template - -When documenting the dataset for team use, include: -- Description. -- Grain. -- Primary key. -- Row count and date. -- Update frequency. -- Owner if known. -- Key columns table. -- Relationships. -- Known issues. -- Common query patterns. - -## SQL Discovery Patterns - -Use dialect-appropriate schema queries. For PostgreSQL-style systems: - -```sql -SELECT table_name, table_type -FROM information_schema.tables -WHERE table_schema = 'public' -ORDER BY table_name; - -SELECT column_name, data_type, is_nullable, column_default -FROM information_schema.columns -WHERE table_name = 'my_table' -ORDER BY ordinal_position; -``` - -For other warehouses, adapt to the warehouse dialect and metadata tables. diff --git a/skills/explore-data/agents/openai.yaml b/skills/explore-data/agents/openai.yaml deleted file mode 100644 index cebf604e..00000000 --- a/skills/explore-data/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Explore Data" - short_description: "Profile and explore a dataset to understand its shape, quality, and patterns. Use when encountering a new table or..." - brand_color: "#0F766E" - default_prompt: "Use $explore-data with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/explore-data/productize.json b/skills/explore-data/productize.json deleted file mode 100644 index dd9c7956..00000000 --- a/skills/explore-data/productize.json +++ /dev/null @@ -1,47 +0,0 @@ -{ - "title": "Explore Data", - "category": "Analytics", - "tags": [ - "data-profiling", - "data-quality", - "schema", - "dataset-exploration", - "null-rates", - "distributions", - "explore-data", - "explore", - "data", - "reporting", - "profile", - "dataset", - "understand", - "analytics" - ], - "lifecycle": "Measure", - "use_when": "Profile and explore a dataset to understand its shape, quality, and patterns. Use when encountering a new table or file, checking null rates and distributions, spotting duplicates or suspicious values, or deciding which dimensions and metrics to analyze.", - "do_not_use_when": "Do not use Explore Data when the request is mainly early ideation, qualitative research, or roadmap writing without metrics; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Explore Data analytics diagnosis with metric readout, caveats, decision, and next instrumented step", - "routing_signals": [ - "explore-data", - "explore", - "data", - "reporting", - "profile", - "dataset", - "understand", - "analytics", - "its" - ], - "framework_fit": "Explore Data fits Analytics work in the Measure lifecycle when the user needs Explore Data analytics diagnosis with metric readout, caveats, decision, and next instrumented step and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Explore Data analytics diagnosis with metric readout, caveats, decision, and next instrumented step without tying recommendations to the user's Measure stage, evidence, and decision pressure.", - "Treats Explore Data as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Explore Data when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $explore-data to turn this explore context into a decision-ready Explore Data analytics diagnosis with metric readout, caveats, decision, and next instrumented step.", - "expected_artifact": "Explore Data analytics diagnosis with metric readout, caveats, decision, and next instrumented step" - } - ] -} diff --git a/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md b/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md deleted file mode 100644 index c0198290..00000000 --- a/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: feature-impact-models-from-kpis-and-assumptions -description: >- - Feature impact models from KPIs and assumptions. Use when the user needs a product workflow - for business analysis related to feature impact models from kpis and assumptions. Trigger - terms: pm, business-analysis, financial-modeling, kpi-impact. ---- - - - -# Feature impact models from KPIs and assumptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-impact-models-from-kpis-and-assumptions` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Feature impact models from KPIs and assumptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_INFO}} -- {{KPIS_TO_ESTIMATE}} - - -GOAL -Produce a high-quality deliverable for: Feature impact models from KPIs and assumptions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Build a procedural task list that covers: - - key assumptions, - - baseline metric calculations, - - per-KPI impact estimation, - - sensitivity analysis. -- Execute the tasks and show calculations step by step using explicit formulas/equations. -- For each KPI, provide: - - point estimate, - - assumptions and calculations used, - - brief explanation of feature-to-KPI impact mechanism. -- If information is missing, state what is missing, add a reasonable assumption, label it clearly, and proceed. -- Prioritize transparent math and reasoning over spreadsheet-like verbosity. -- Keep conclusions focused on executive decision-making (investment impact, major drivers, key risks). - - -FORMAT -Return exactly this structure: - - - -[List the procedural tasks used to build the model] - - - -[Step-by-step calculations, formulas, assumptions, and point estimates for each KPI] - - - -[Feature overview, KPI estimate table/list, key assumptions, sensitivity-analysis takeaways, and executive conclusions] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md.tmpl b/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md.tmpl deleted file mode 100644 index 622c2b94..00000000 --- a/skills/feature-impact-models-from-kpis-and-assumptions/SKILL.md.tmpl +++ /dev/null @@ -1,79 +0,0 @@ ---- -name: feature-impact-models-from-kpis-and-assumptions -description: >- - Feature impact models from KPIs and assumptions. Use when the user needs a product workflow - for business analysis related to feature impact models from kpis and assumptions. Trigger - terms: pm, business-analysis, financial-modeling, kpi-impact. ---- -# Feature impact models from KPIs and assumptions - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Feature impact models from KPIs and assumptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_INFO}} -- {{KPIS_TO_ESTIMATE}} - - -GOAL -Produce a high-quality deliverable for: Feature impact models from KPIs and assumptions. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Build a procedural task list that covers: - - key assumptions, - - baseline metric calculations, - - per-KPI impact estimation, - - sensitivity analysis. -- Execute the tasks and show calculations step by step using explicit formulas/equations. -- For each KPI, provide: - - point estimate, - - assumptions and calculations used, - - brief explanation of feature-to-KPI impact mechanism. -- If information is missing, state what is missing, add a reasonable assumption, label it clearly, and proceed. -- Prioritize transparent math and reasoning over spreadsheet-like verbosity. -- Keep conclusions focused on executive decision-making (investment impact, major drivers, key risks). - - -FORMAT -Return exactly this structure: - - - -[List the procedural tasks used to build the model] - - - -[Step-by-step calculations, formulas, assumptions, and point estimates for each KPI] - - - -[Feature overview, KPI estimate table/list, key assumptions, sensitivity-analysis takeaways, and executive conclusions] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/feature-impact-models-from-kpis-and-assumptions/agents/openai.yaml b/skills/feature-impact-models-from-kpis-and-assumptions/agents/openai.yaml deleted file mode 100644 index 9f806c5a..00000000 --- a/skills/feature-impact-models-from-kpis-and-assumptions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Feature impact models from KPIs and assumptions" - short_description: "Feature impact models from KPIs and assumptions. Use when the user needs a product workflow for business analysis..." - brand_color: "#0D9488" - default_prompt: "Use $feature-impact-models-from-kpis-and-assumptions with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/feature-impact-models-from-kpis-and-assumptions/productize.json b/skills/feature-impact-models-from-kpis-and-assumptions/productize.json deleted file mode 100644 index ea69a85c..00000000 --- a/skills/feature-impact-models-from-kpis-and-assumptions/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Feature impact models from KPIs and assumptions", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "feature-impact-models-from-kpis-and-assumptions", - "feature", - "impact", - "models", - "kpis", - "assumptions" - ], - "use_when": "Feature impact models from KPIs and assumptions. Use when the user needs a product workflow for business analysis related to feature impact models from kpis and assumptions. Trigger terms: pm, business-analysis, financial-modeling, kpi-impact.", - "do_not_use_when": "Do not use Feature impact models from KPIs and assumptions when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "feature-impact-models-from-kpis-and-assumptions", - "feature", - "impact", - "models", - "kpis", - "assumptions" - ], - "framework_fit": "Feature impact models from KPIs and assumptions fits Discovery work in the Discover lifecycle when the user needs Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Feature impact models from KPIs and assumptions as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Feature impact models from KPIs and assumptions when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $feature-impact-models-from-kpis-and-assumptions to turn this feature context into a decision-ready Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Feature impact models from KPIs and assumptions research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md b/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md deleted file mode 100644 index 73a774b8..00000000 --- a/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- - - - -# Feature results analysis from draft to final report - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `feature-results-analysis-from-draft-to-final-report` -- **Lifecycle**: Launch & Learn -- **Category**: Analytics -- **Primary artifact**: Feature results readout with iterate, rollback, kill, or scale recommendation - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md.tmpl b/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md.tmpl deleted file mode 100644 index 1ed4c932..00000000 --- a/skills/feature-results-analysis-from-draft-to-final-report/SKILL.md.tmpl +++ /dev/null @@ -1,82 +0,0 @@ ---- -name: feature-results-analysis-from-draft-to-final-report -description: >- - Feature results analysis from draft to final report. Use when the user needs a product - workflow for business analysis related to feature results analysis from draft to final - report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, - reporting. ---- -# Feature results analysis from draft to final report - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Feature results analysis from draft to final report**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRW_DRAFT}} - - -GOAL -Evaluate an FRW draft rigorously and produce both prioritized feedback and a stronger rewritten FRW with placeholders where data is missing. -Success metric: -- Feedback identifies critical analytical and reporting issues in priority order. -- Rewritten FRW demonstrates sound experimentation logic, statistical interpretation, and business relevance. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -- Review `FRW_DRAFT` thoroughly for: - - statistical validity/significance claims, - - methodology clarity/completeness, - - interpretation quality, - - alignment to business goals, - - potential bias/confounding factors, - - actionability and decision-readiness, - - structure and narrative flow. -- Provide prioritized feedback (highest-risk issues first), including: - - strengths, - - issues and improvements, - - additional metrics/data recommendations, - - presentation/communication improvements, - - stronger conclusion/recommendation guidance. -- Rewrite the FRW with placeholders where data is absent. -- In the rewrite, include at minimum: - - experiment context/objective, - - methodology and guardrails, - - results with statistical interpretation, - - business impact interpretation, - - risks/limitations, - - recommendations and next actions. -- Mark assumptions and placeholders explicitly (e.g., `[ASSUMPTION]`, `[PLACEHOLDER_METRIC]`). - - -FORMAT -Return exactly this structure: - - -[Detailed, prioritized feedback with clear subheadings] - - -[Complete rewritten FRW using placeholders and explicit assumptions where needed] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/feature-results-analysis-from-draft-to-final-report/agents/openai.yaml b/skills/feature-results-analysis-from-draft-to-final-report/agents/openai.yaml deleted file mode 100644 index 4abca143..00000000 --- a/skills/feature-results-analysis-from-draft-to-final-report/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Feature results analysis from draft to final report" - short_description: "Feature results analysis from draft to final report. Use when the user needs a product workflow for business..." - brand_color: "#0F766E" - default_prompt: "Use $feature-results-analysis-from-draft-to-final-report with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/feature-results-analysis-from-draft-to-final-report/productize.json b/skills/feature-results-analysis-from-draft-to-final-report/productize.json deleted file mode 100644 index c74788c5..00000000 --- a/skills/feature-results-analysis-from-draft-to-final-report/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Feature results analysis from draft to final report", - "category": "Analytics", - "lifecycle": "Launch & Learn", - "tags": [ - "feature-results-analysis-from-draft-to-final-report", - "feature", - "results", - "draft", - "final", - "report" - ], - "use_when": "Feature results analysis from draft to final report. Use when the user needs a product workflow for business analysis related to feature results analysis from draft to final report. Trigger terms: pm, business-analysis, experimentation, ab-testing, analysis, reporting.", - "do_not_use_when": "Do not use Feature results analysis from draft to final report when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Feature results readout with iterate, rollback, kill, or scale recommendation", - "routing_signals": [ - "feature-results-analysis-from-draft-to-final-report", - "feature", - "results", - "draft", - "final", - "report" - ], - "framework_fit": "Appropriate when a launched feature, experiment, or beta needs results analysis, adoption diagnosis, and a clear decision on what to do next.", - "failure_modes": [ - "Produces Feature results readout with iterate, rollback, kill, or scale recommendation without tying recommendations to the user's Launch & Learn stage, evidence, and decision pressure.", - "Treats Feature results analysis from draft to final report as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Feature results analysis from draft to final report when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $feature-results-analysis-from-draft-to-final-report to turn this feature context into a decision-ready Feature results readout with iterate, rollback, kill, or scale recommendation.", - "expected_artifact": "Feature results readout with iterate, rollback, kill, or scale recommendation" - } - ] -} diff --git a/skills/features-reframing-and-projects-shape-up/SKILL.md b/skills/features-reframing-and-projects-shape-up/SKILL.md deleted file mode 100644 index b8dffefb..00000000 --- a/skills/features-reframing-and-projects-shape-up/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: features-reframing-and-projects-shape-up -description: >- - Features reframing and projects Shape Up. Use when the user needs a product workflow for - technical related to features reframing and projects shape up. Trigger terms: - product-strategy, shaping, scope-management, stakeholder-management, technical. ---- - - - -# Features reframing and projects Shape Up - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `features-reframing-and-projects-shape-up` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks - -Use this skill to run the Productize prompt contract for **Features reframing and projects Shape Up**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_OR_PROJECT}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Features reframing and projects Shape Up. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reframe `{{FEATURE_OR_PROJECT}}` using Shape Up principles and provided `{{CONTEXT}}`. -- Provide a shaped work definition that is concrete enough for delivery but avoids build-phase implementation detail. -- Include: -- Appetite assessment (`1-2 weeks` or `6 weeks`) with rationale. -- Problem framing (problem-first, not solution-first). -- Boundary definition (in-scope / out-of-scope). -- Solution sketch at fat-marker level. -- Risks/rabbit holes and circuit-breakers. -- Explicit no-gos. -- Executive constraint language to secure scope commitment and prevent mid-cycle scope creep. -- Keep output focused on shaping quality, delivery constraints, and stakeholder alignment. - -FORMAT -Return exactly this structure: - -Shape Up Reframe - -Appetite Assessment -- Recommended appetite: [1-2 weeks or 6 weeks] -- Why this appetite: [rationale] - -Problem Framing -- Core problem: [problem statement] -- Why this matters now: [impact/context] -- Success condition: [what success looks like] - -Boundary Definition -- In scope: - - [item] -- Out of scope: - - [item] - -Solution Sketching (Fat Marker Level) -- Key approach: [high-level approach] -- Main interaction/surface 1: [conceptual behavior] -- Main interaction/surface 2: [conceptual behavior] - -Risks and Rabbit Holes -- [risk/rabbit hole] -- Circuit-breaker: [constraint or stop-rule] - -No-gos -- [explicit exclusion] - -Executive Constraints -- Commitment language: [specific wording to secure scope agreement] -- Change-control rule: [how new requests are handled mid-cycle] -- Escalation path: [who decides if scope must change] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Output drifts into build-phase implementation details instead of shaping-level decisions. -- Boundaries/no-gos are vague or do not constrain scope. -- Executive constraint handling is missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/features-reframing-and-projects-shape-up/SKILL.md.tmpl b/skills/features-reframing-and-projects-shape-up/SKILL.md.tmpl deleted file mode 100644 index fc2b4717..00000000 --- a/skills/features-reframing-and-projects-shape-up/SKILL.md.tmpl +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: features-reframing-and-projects-shape-up -description: >- - Features reframing and projects Shape Up. Use when the user needs a product workflow for - technical related to features reframing and projects shape up. Trigger terms: - product-strategy, shaping, scope-management, stakeholder-management, technical. ---- -# Features reframing and projects Shape Up - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Features reframing and projects Shape Up**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FEATURE_OR_PROJECT}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Features reframing and projects Shape Up. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Reframe `{{FEATURE_OR_PROJECT}}` using Shape Up principles and provided `{{CONTEXT}}`. -- Provide a shaped work definition that is concrete enough for delivery but avoids build-phase implementation detail. -- Include: -- Appetite assessment (`1-2 weeks` or `6 weeks`) with rationale. -- Problem framing (problem-first, not solution-first). -- Boundary definition (in-scope / out-of-scope). -- Solution sketch at fat-marker level. -- Risks/rabbit holes and circuit-breakers. -- Explicit no-gos. -- Executive constraint language to secure scope commitment and prevent mid-cycle scope creep. -- Keep output focused on shaping quality, delivery constraints, and stakeholder alignment. - -FORMAT -Return exactly this structure: - -Shape Up Reframe - -Appetite Assessment -- Recommended appetite: [1-2 weeks or 6 weeks] -- Why this appetite: [rationale] - -Problem Framing -- Core problem: [problem statement] -- Why this matters now: [impact/context] -- Success condition: [what success looks like] - -Boundary Definition -- In scope: - - [item] -- Out of scope: - - [item] - -Solution Sketching (Fat Marker Level) -- Key approach: [high-level approach] -- Main interaction/surface 1: [conceptual behavior] -- Main interaction/surface 2: [conceptual behavior] - -Risks and Rabbit Holes -- [risk/rabbit hole] -- Circuit-breaker: [constraint or stop-rule] - -No-gos -- [explicit exclusion] - -Executive Constraints -- Commitment language: [specific wording to secure scope agreement] -- Change-control rule: [how new requests are handled mid-cycle] -- Escalation path: [who decides if scope must change] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Output drifts into build-phase implementation details instead of shaping-level decisions. -- Boundaries/no-gos are vague or do not constrain scope. -- Executive constraint handling is missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/features-reframing-and-projects-shape-up/agents/openai.yaml b/skills/features-reframing-and-projects-shape-up/agents/openai.yaml deleted file mode 100644 index 96c6447b..00000000 --- a/skills/features-reframing-and-projects-shape-up/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Features reframing and projects Shape Up" - short_description: "Features reframing and projects Shape Up. Use when the user needs a product workflow for technical related to..." - brand_color: "#334155" - default_prompt: "Use $features-reframing-and-projects-shape-up with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/features-reframing-and-projects-shape-up/productize.json b/skills/features-reframing-and-projects-shape-up/productize.json deleted file mode 100644 index 379d5202..00000000 --- a/skills/features-reframing-and-projects-shape-up/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Features reframing and projects Shape Up", - "category": "AI Execution", - "lifecycle": "Build With AI", - "tags": [ - "features-reframing-and-projects-shape-up", - "features", - "reframing", - "projects", - "shape", - "technical", - "execution" - ], - "use_when": "Features reframing and projects Shape Up. Use when the user needs a product workflow for technical related to features reframing and projects shape up. Trigger terms: product-strategy, shaping, scope-management, stakeholder-management, technical.", - "do_not_use_when": "Do not use Features reframing and projects Shape Up when the request is mainly market strategy, research synthesis, finance modeling, or executive communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks", - "routing_signals": [ - "features-reframing-and-projects-shape-up", - "features", - "reframing", - "projects", - "shape", - "technical", - "execution" - ], - "framework_fit": "Features reframing and projects Shape Up fits AI Execution work in the Build With AI lifecycle when the user needs Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats Features reframing and projects Shape Up as generic AI Execution advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Features reframing and projects Shape Up when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $features-reframing-and-projects-shape-up to turn this features context into a decision-ready Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks.", - "expected_artifact": "Features reframing and projects Shape Up AI-builder handoff with implementation scope, verification plan, and risks" - } - ] -} diff --git a/skills/final-verify/SKILL.md b/skills/final-verify/SKILL.md new file mode 100644 index 00000000..15943c67 --- /dev/null +++ b/skills/final-verify/SKILL.md @@ -0,0 +1,154 @@ +--- +name: final-verify +description: Enforces fresh verification evidence before any completion, fix, or passing claim, and before commits or PR creation. Use when an agent is about to report success, hand off work, or commit code. Do not use for early planning, brainstorming, or tasks that have not yet reached a concrete verification step. +--- + +# Verification Before Completion + +## Overview + +Claiming work is complete without verification is dishonesty, not efficiency. + +**Core principle:** Evidence before claims, always. + +**Violating the letter of this rule is violating the spirit of this rule.** + +## The Iron Law + +``` +NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE +``` + +If the verification command has not been run in the current message, the result cannot be claimed. + +## The Gate Function + +``` +BEFORE claiming any status or expressing satisfaction: + +1. IDENTIFY: What command proves this claim? +2. RUN: Execute the FULL command (fresh, complete) +3. READ: Full output, check exit code, count failures +4. VERIFY: Does output confirm the claim? + - If NO: State actual status with evidence + - If YES: State claim WITH evidence +5. ONLY THEN: Make the claim + +Skip any step = lying, not verifying +``` + +## Scope of Verification + +Match the verification scope to the claim scope: + +- **Narrow claim** (e.g., "this test passes"): Run the specific test. +- **Broad claim** (e.g., "task complete", "ready to commit"): Run the **full verification pipeline** โ€” formatting, linting, all tests, and build. If the project defines a single gate command (e.g., `make verify`), run that. + +A narrow verification does not support a broad claim. Running `make test` alone does not justify "task complete." Running the linter alone does not justify "ready to commit." The verification scope must be equal to or broader than the claim scope. + +**If in doubt, run the full pipeline.** Over-verification wastes minutes. Under-verification wastes hours. + +**Passing pipeline != meeting requirements.** A green build proves the code compiles, lints, and passes existing tests. It does not prove the implementation matches the requirements. For "task complete" or "requirements met" claims, also verify the deliverables against the original specification โ€” line by line, not by assumption. + +## Common Failures + +| Claim | Requires | Not Sufficient | +| --------------------- | ------------------------------- | ------------------------------ | +| Tests pass | Test command output: 0 failures | Previous run, "should pass" | +| Linter clean | Linter output: 0 errors | Partial check, extrapolation | +| Build succeeds | Build command: exit 0 | Linter passing, logs look good | +| Bug fixed | Test original symptom: passes | Code changed, assumed fixed | +| Regression test works | Red-green cycle verified | Test passes once | +| Agent completed | VCS diff shows changes | Agent reports "success" | +| Requirements met | Line-by-line checklist | Tests passing | + +## Red Flags + +- Using "should", "probably", or "seems to" +- Expressing satisfaction before verification +- About to commit, push, or open a PR without verification +- Trusting another agent's success report +- Relying on partial verification +- Thinking "just this once" +- Any wording that implies success without current evidence + +## Rationalization Prevention + +| Excuse | Reality | +| --------------------------------------- | ---------------------- | +| "Should work now" | Run the verification | +| "I'm confident" | Confidence โ‰  evidence | +| "Just this once" | No exceptions | +| "Linter passed" | Linter โ‰  compiler | +| "Agent said success" | Verify independently | +| "I'm tired" | Exhaustion โ‰  excuse | +| "Partial check is enough" | Partial proves nothing | +| "Different words so rule doesn't apply" | Spirit over letter | + +## When To Apply + +Apply this skill before: + +- any success or completion claim +- any expression of satisfaction with the implementation state +- any commit or PR creation +- any handoff that implies correctness +- moving to the next task based on completion + +## Pre-Commit and Pre-PR Gate + +Commits and PRs are permanent artifacts. They require the highest verification standard. + +**Before `git commit`:** +1. Run the full verification pipeline (e.g., `make verify`). Not a subset. The full pipeline. +2. Confirm zero errors, zero warnings, zero test failures in the output. +3. Produce a Verification Report (see template below) with verdict PASS. +4. Only then run `git commit`. + +**Before creating a PR:** +1. All of the above, plus: +2. Verify the diff matches the intended changes (`git diff` review). +3. Confirm no unrelated files are staged. + +If the full pipeline has not passed in this session after the last code change, the commit or PR must not proceed. + +## Verification Report Template + +Verification is not complete until the agent **cites actual command output** in their response. "I ran it and it passed" is not evidence. If the verification output is not shown, the verification did not happen. + +Every verification must be reported using this structure. Do not deviate. + +``` +VERIFICATION REPORT +------------------- +Claim: [What is being claimed โ€” e.g., "tests pass", "build succeeds", "task complete"] +Command: [Exact command run โ€” e.g., `make verify`] +Executed: [Timestamp or "just now, after all changes"] +Exit code: [0 or non-zero] +Output summary: [Key lines from output โ€” pass count, error count, build result] +Warnings: [Any warnings, or "none"] +Errors: [Any errors, or "none"] +Verdict: PASS or FAIL +``` + +If the verdict is FAIL, do not use completion language. State what failed and what remains. + +If the verdict is PASS, the claim may proceed โ€” but only the specific claim supported by the evidence. "Tests pass" does not mean "build succeeds." + +## When Verification Fails + +Verification failure is not a dead end. It is information. Follow this protocol: + +1. **Read the failure.** Identify the exact error: which command failed, which test, which lint rule, which build error. Quote the relevant output lines. +2. **Diagnose the root cause.** Do not guess. Read the error message. Trace it to the source. If multiple things failed, address them one at a time starting with the first failure. +3. **Fix the root cause.** Apply the minimal change that addresses the actual error. Do not apply workarounds, suppress warnings, or skip checks. +4. **Re-verify from scratch.** Run the full verification command again. Do not assume the fix worked. Do not run only the previously-failing subset. +5. **Report with evidence.** Use the Verification Report Template. If it passes now, the claim may proceed. If it fails again, return to step 1. + +**Never:** +- Claim partial success ("3 of 4 checks pass, close enough") +- Skip re-verification after a fix ("I fixed the error, so it should pass now") +- Blame the tooling ("the linter is wrong") without evidence of a false positive +- Move on to the next task while verification is still failing + +If the correct verification command is unclear, identify it before making any completion claim. If only partial verification is available, state that limitation explicitly and avoid completion language. diff --git a/skills/finance-modeling-kernel/SKILL.md b/skills/finance-modeling-kernel/SKILL.md deleted file mode 100644 index 5f4052fc..00000000 --- a/skills/finance-modeling-kernel/SKILL.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -name: finance-modeling-kernel -description: >- - Shared Productize Finance calculation and validation kernel for exact formulas, - input normalization, assumption checks, units, warnings, and acceptance-tested - finance math used by valuation, DCF, cost-of-capital, capital-structure, VC deal, - and market-context skills. ---- - - - -# Finance Modeling Kernel - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `finance-modeling-kernel` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings - -## Purpose - -Shared calculation and validation library used by all Productize Finance skills. -Use this skill when a finance workflow needs exact formulas, normalized inputs, -assumption checks, error handling, units, or validation before making a recommendation. - -## Kernel Modules - -- `finance-modeling-kernel/time_value.py`: PV, FV, annuities, perpetuities, spot-rate streams. -- `finance-modeling-kernel/dcf.py`: NPV, IRR, payback, free cash flow, terminal value, ROIC, growth. -- `finance-modeling-kernel/returns.py`: realized returns, expected return, variance, volatility, covariance, correlation. -- `finance-modeling-kernel/risk.py`: portfolio variance, covariance, correlation, beta, regression beta. -- `finance-modeling-kernel/capm.py`: CAPM, unlevered beta, relevered beta. -- `finance-modeling-kernel/wacc.py`: WACC with market-value weights. -- `finance-modeling-kernel/apv.py`: tax shields and APV. -- `finance-modeling-kernel/valuation.py`: DCF valuation, terminal value, EV-to-equity bridge, multiples, sensitivities. -- `finance-modeling-kernel/capital_structure.py`: EV, equity value, leverage, MM, tax shields, APV. -- `finance-modeling-kernel/bond_math.py`: bond price, yield to maturity, current yield, credit spread. -- `finance-modeling-kernel/vc_method.py`: burn, runway, VC target multiple, pre/post-money, shares. -- `finance-modeling-kernel/cap_table.py`: fully diluted shares, ownership, dilution, cap table sum checks. -- `finance-modeling-kernel/convertible_notes.py`: note conversion amount, discount price, cap price, shares. -- `finance-modeling-kernel/safes.py`: SAFE conversion price, SAFE shares, post-money SAFE ownership. -- `finance-modeling-kernel/preferred_stock.py`: liquidation preference and preferred payoff waterfalls. -- `finance-modeling-kernel/option_pools.py`: investor-friendly and founder-friendly option pool math. -- `finance-modeling-kernel/market_context.py`: market cap, weights, listing changes, CAGR. -- `finance-modeling-kernel/validation.py`: shared validation errors and warning helpers. -- `finance-modeling-kernel/tests/`: acceptance tests for the minimum formula examples. - -## Finance Output Format - -All Productize Finance agents must return: - -1. **Inputs** -2. **Assumptions** -3. **Formula used** -4. **Calculation** -5. **Result** -6. **Interpretation** -7. **Warnings** - -## Global Guardrails - -1. Never compare cash flows at different dates without compounding or discounting. -2. Use market values, not book values, for valuation and WACC weights whenever possible. -3. Match discount rates to cash-flow risk. -4. Do not use a company WACC for a project with materially different risk. -5. Do not mix financing cash flows into operating free cash flow. -6. Use NPV as the primary investment decision rule. -7. Treat IRR, payback, and multiples as supporting tools, not final truth. -8. For VC deals, always state whether share counts are basic or fully diluted. -9. For option pools, always state whether the pool is investor-friendly or founder-friendly. -10. For convertible notes and SAFEs, always read the conversion definition before calculating. -11. For preferred stock, model the payoff waterfall, not only the ownership percentage. - -## Workflow - -1. Identify the finance problem and the cash-flow timing, units, currency, and risk basis. -2. Choose the exact module and function; do not invent ad hoc formulas when a kernel function exists. -3. Validate formula preconditions, especially `r > g`, positive denominators, share-count basis, and market-value weights. -4. Calculate transparently enough that the user can audit the math. -5. Return the standard Finance output format and warnings. - -## Acceptance Tests - -Run: - -```sh -python3 skills/finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py -``` - -The test suite covers DCF NPV, growing perpetuity, CAPM, WACC, VC target multiple, -post-money/pre-money, convertible note discount conversion, investor-friendly option -pool, and non-participating preferred payoff. diff --git a/skills/finance-modeling-kernel/SKILL.md.tmpl b/skills/finance-modeling-kernel/SKILL.md.tmpl deleted file mode 100644 index fc281b2a..00000000 --- a/skills/finance-modeling-kernel/SKILL.md.tmpl +++ /dev/null @@ -1,86 +0,0 @@ ---- -name: finance-modeling-kernel -description: >- - Shared Productize Finance calculation and validation kernel for exact formulas, - input normalization, assumption checks, units, warnings, and acceptance-tested - finance math used by valuation, DCF, cost-of-capital, capital-structure, VC deal, - and market-context skills. ---- - -# Finance Modeling Kernel - -{{PRODUCTIZE_PREAMBLE}} - -## Purpose - -Shared calculation and validation library used by all Productize Finance skills. -Use this skill when a finance workflow needs exact formulas, normalized inputs, -assumption checks, error handling, units, or validation before making a recommendation. - -## Kernel Modules - -- `finance-modeling-kernel/time_value.py`: PV, FV, annuities, perpetuities, spot-rate streams. -- `finance-modeling-kernel/dcf.py`: NPV, IRR, payback, free cash flow, terminal value, ROIC, growth. -- `finance-modeling-kernel/returns.py`: realized returns, expected return, variance, volatility, covariance, correlation. -- `finance-modeling-kernel/risk.py`: portfolio variance, covariance, correlation, beta, regression beta. -- `finance-modeling-kernel/capm.py`: CAPM, unlevered beta, relevered beta. -- `finance-modeling-kernel/wacc.py`: WACC with market-value weights. -- `finance-modeling-kernel/apv.py`: tax shields and APV. -- `finance-modeling-kernel/valuation.py`: DCF valuation, terminal value, EV-to-equity bridge, multiples, sensitivities. -- `finance-modeling-kernel/capital_structure.py`: EV, equity value, leverage, MM, tax shields, APV. -- `finance-modeling-kernel/bond_math.py`: bond price, yield to maturity, current yield, credit spread. -- `finance-modeling-kernel/vc_method.py`: burn, runway, VC target multiple, pre/post-money, shares. -- `finance-modeling-kernel/cap_table.py`: fully diluted shares, ownership, dilution, cap table sum checks. -- `finance-modeling-kernel/convertible_notes.py`: note conversion amount, discount price, cap price, shares. -- `finance-modeling-kernel/safes.py`: SAFE conversion price, SAFE shares, post-money SAFE ownership. -- `finance-modeling-kernel/preferred_stock.py`: liquidation preference and preferred payoff waterfalls. -- `finance-modeling-kernel/option_pools.py`: investor-friendly and founder-friendly option pool math. -- `finance-modeling-kernel/market_context.py`: market cap, weights, listing changes, CAGR. -- `finance-modeling-kernel/validation.py`: shared validation errors and warning helpers. -- `finance-modeling-kernel/tests/`: acceptance tests for the minimum formula examples. - -## Finance Output Format - -All Productize Finance agents must return: - -1. **Inputs** -2. **Assumptions** -3. **Formula used** -4. **Calculation** -5. **Result** -6. **Interpretation** -7. **Warnings** - -## Global Guardrails - -1. Never compare cash flows at different dates without compounding or discounting. -2. Use market values, not book values, for valuation and WACC weights whenever possible. -3. Match discount rates to cash-flow risk. -4. Do not use a company WACC for a project with materially different risk. -5. Do not mix financing cash flows into operating free cash flow. -6. Use NPV as the primary investment decision rule. -7. Treat IRR, payback, and multiples as supporting tools, not final truth. -8. For VC deals, always state whether share counts are basic or fully diluted. -9. For option pools, always state whether the pool is investor-friendly or founder-friendly. -10. For convertible notes and SAFEs, always read the conversion definition before calculating. -11. For preferred stock, model the payoff waterfall, not only the ownership percentage. - -## Workflow - -1. Identify the finance problem and the cash-flow timing, units, currency, and risk basis. -2. Choose the exact module and function; do not invent ad hoc formulas when a kernel function exists. -3. Validate formula preconditions, especially `r > g`, positive denominators, share-count basis, and market-value weights. -4. Calculate transparently enough that the user can audit the math. -5. Return the standard Finance output format and warnings. - -## Acceptance Tests - -Run: - -```sh -python3 skills/finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py -``` - -The test suite covers DCF NPV, growing perpetuity, CAPM, WACC, VC target multiple, -post-money/pre-money, convertible note discount conversion, investor-friendly option -pool, and non-participating preferred payoff. diff --git a/skills/finance-modeling-kernel/agents/openai.yaml b/skills/finance-modeling-kernel/agents/openai.yaml deleted file mode 100644 index be8cf712..00000000 --- a/skills/finance-modeling-kernel/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Finance Modeling Kernel" - short_description: "Shared Productize Finance calculation and validation kernel for exact formulas, input normalization, assumption..." - brand_color: "#0369A1" - default_prompt: "Use $finance-modeling-kernel with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/apv.py b/skills/finance-modeling-kernel/finance-modeling-kernel/apv.py deleted file mode 100644 index 754f2374..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/apv.py +++ /dev/null @@ -1,10 +0,0 @@ -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/bond_math.py b/skills/finance-modeling-kernel/finance-modeling-kernel/bond_math.py deleted file mode 100644 index bbbe83d7..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/bond_math.py +++ /dev/null @@ -1,36 +0,0 @@ -from validation import FinanceValidationError, require_positive - - -def bond_price(coupon, face_value, yield_to_maturity, periods): - if yield_to_maturity == 0: - return coupon * periods + face_value - return coupon * (1 - (1 + yield_to_maturity) ** (-periods)) / yield_to_maturity + face_value / (1 + yield_to_maturity) ** periods - - -def yield_to_maturity(price, coupon, face_value, periods, tolerance=1e-7, max_iterations=200): - require_positive("price", price) - low = -0.999999 - high = 1.0 - while bond_price(coupon, face_value, high, periods) > price and high < 1000: - high *= 2 - if high >= 1000: - raise FinanceValidationError("Yield to maturity could not be bracketed.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_price = bond_price(coupon, face_value, mid, periods) - if abs(mid_price - price) <= tolerance: - return mid - if mid_price > price: - low = mid - else: - high = mid - return (low + high) / 2 - - -def current_yield(annual_coupon, bond_price_value): - require_positive("bond_price", bond_price_value) - return annual_coupon / bond_price_value - - -def credit_spread(risky_yield, risk_free_yield): - return risky_yield - risk_free_yield diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/cap_table.py b/skills/finance-modeling-kernel/finance-modeling-kernel/cap_table.py deleted file mode 100644 index 73d96466..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/cap_table.py +++ /dev/null @@ -1,19 +0,0 @@ -from validation import require_positive - - -def fully_diluted_shares(common=0, preferred_as_converted=0, options_issued=0, option_pool_unissued=0, warrants=0, convertibles=0): - return common + preferred_as_converted + options_issued + option_pool_unissued + warrants + convertibles - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares - - -def dilution(old_ownership_percentage, new_ownership_percentage): - require_positive("old_ownership_percentage", old_ownership_percentage) - return 1 - new_ownership_percentage / old_ownership_percentage - - -def cap_table_sums_to_100(ownership_percentages, tolerance=1e-6): - return abs(sum(ownership_percentages) - 1) <= tolerance diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/capital_structure.py b/skills/finance-modeling-kernel/finance-modeling-kernel/capital_structure.py deleted file mode 100644 index e8e7565e..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/capital_structure.py +++ /dev/null @@ -1,51 +0,0 @@ -from validation import require_positive - - -def enterprise_value(equity_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return equity_value + debt + preferred_stock + minority_interest - cash - nonoperating_assets - - -def equity_value_from_ev(enterprise_value_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def debt_to_equity(debt, equity): - require_positive("equity", equity) - return debt / equity - - -def debt_to_value(debt, equity): - require_positive("debt plus equity", debt + equity) - return debt / (debt + equity) - - -def degree_of_financial_leverage(ebit, interest): - require_positive("ebit minus interest", ebit - interest) - return ebit / (ebit - interest) - - -def wacc(equity, debt, cost_of_equity, cost_of_debt, tax_rate): - total = equity + debt - require_positive("debt plus equity", total) - return equity / total * cost_of_equity + debt / total * (1 - tax_rate) * cost_of_debt - - -def mm_value_no_taxes(unlevered_value): - return unlevered_value - - -def mm_cost_of_equity_no_taxes(unlevered_cost_of_capital, cost_of_debt, debt, equity): - require_positive("equity", equity) - return unlevered_cost_of_capital + debt / equity * (unlevered_cost_of_capital - cost_of_debt) - - -def tax_shield(interest, tax_rate): - return tax_rate * interest - - -def pv_tax_shield_perpetual(debt, tax_rate): - return tax_rate * debt - - -def apv(base_case_npv, pv_tax_shields, pv_distress_costs=0, issuance_costs=0): - return base_case_npv + pv_tax_shields - pv_distress_costs - issuance_costs diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/capm.py b/skills/finance-modeling-kernel/finance-modeling-kernel/capm.py deleted file mode 100644 index 19a58da7..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/capm.py +++ /dev/null @@ -1,21 +0,0 @@ -from validation import require_positive - - -def capm_cost_of_equity(risk_free_rate, beta, market_risk_premium): - return risk_free_rate + beta * market_risk_premium - - -def unlever_beta(beta_l, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_l / (1 + (1 - tax_rate) * debt / equity) - - -def relever_beta(beta_u, debt, equity, tax_rate): - require_positive("equity", equity) - return beta_u * (1 + (1 - tax_rate) * debt / equity) - - -def asset_beta_with_debt_beta(beta_equity, beta_debt, debt, equity, tax_rate=0): - require_positive("total capital", debt + equity) - tax_adjusted_debt = debt * (1 - tax_rate) - return (beta_equity * equity + beta_debt * tax_adjusted_debt) / (equity + tax_adjusted_debt) diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py b/skills/finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py deleted file mode 100644 index 9d05470a..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/convertible_notes.py +++ /dev/null @@ -1,27 +0,0 @@ -from validation import require_positive - - -def convertible_note_conversion_amount(principal, interest_rate, time, compounding_method="simple"): - if compounding_method == "simple": - return principal * (1 + interest_rate * time) - if compounding_method == "compound": - return principal * (1 + interest_rate) ** time - raise ValueError("compounding_method must be simple or compound.") - - -def convertible_note_discount_price(series_a_price, discount_rate): - return (1 - discount_rate) * series_a_price - - -def convertible_note_cap_price(valuation_cap, cap_share_count): - require_positive("cap_share_count", cap_share_count) - return valuation_cap / cap_share_count - - -def convertible_note_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def convertible_note_shares(conversion_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return conversion_amount / conversion_price diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/dcf.py b/skills/finance-modeling-kernel/finance-modeling-kernel/dcf.py deleted file mode 100644 index 204cb98b..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/dcf.py +++ /dev/null @@ -1,73 +0,0 @@ -from validation import FinanceValidationError, require_positive, require_rate_greater_than_growth - - -def npv(initial_investment, cash_flows, discount_rate): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def npv_with_terminal_value(initial_investment, fcfs, discount_rate, terminal_value): - return npv(initial_investment, fcfs, discount_rate) + terminal_value / (1 + discount_rate) ** len(fcfs) - - -def irr(cash_flows, tolerance=1e-7, max_iterations=200): - def value(rate): - return sum(cash_flow / (1 + rate) ** period for period, cash_flow in enumerate(cash_flows)) - - low = -0.999999 - high = 1.0 - low_value = value(low) - high_value = value(high) - while low_value * high_value > 0 and high < 1000: - high *= 2 - high_value = value(high) - if low_value * high_value > 0: - raise FinanceValidationError("IRR could not be bracketed; cash flows may have no real IRR or multiple IRRs.") - for _ in range(max_iterations): - mid = (low + high) / 2 - mid_value = value(mid) - if abs(mid_value) <= tolerance: - return mid - if low_value * mid_value < 0: - high = mid - high_value = mid_value - else: - low = mid - low_value = mid_value - return (low + high) / 2 - - -def payback_period(cash_flows): - cumulative = 0 - for period, cash_flow in enumerate(cash_flows): - cumulative += cash_flow - if cumulative >= 0: - return period - return None - - -def discounted_payback_period(cash_flows, discount_rate): - discounted = [cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows)] - return payback_period(discounted) - - -def free_cash_flow(ebit, tax_rate, depreciation, capex, delta_nwc): - return ebit * (1 - tax_rate) + depreciation - capex - delta_nwc - - -def terminal_value_gordon(fcf_next, discount_rate, growth_rate): - require_rate_greater_than_growth(discount_rate, growth_rate, "discount_rate") - return fcf_next / (discount_rate - growth_rate) - - -def roic(nopat, invested_capital): - require_positive("invested_capital", invested_capital) - return nopat / invested_capital - - -def reinvestment_rate(capex, depreciation, delta_nwc, nopat): - require_positive("nopat", nopat) - return (capex - depreciation + delta_nwc) / nopat - - -def sustainable_growth(roic_value, reinvestment_rate_value): - return roic_value * reinvestment_rate_value diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/market_context.py b/skills/finance-modeling-kernel/finance-modeling-kernel/market_context.py deleted file mode 100644 index 7596a040..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/market_context.py +++ /dev/null @@ -1,34 +0,0 @@ -from validation import require_positive - - -def market_cap(price, shares_outstanding): - return price * shares_outstanding - - -def market_weight(company_market_cap, total_market_cap): - require_positive("total_market_cap", total_market_cap) - return company_market_cap / total_market_cap - - -def index_weight(company_market_cap, index_total_market_cap): - require_positive("index_total_market_cap", index_total_market_cap) - return company_market_cap / index_total_market_cap - - -def global_lookthrough_weight(index_weight_value, index_share_of_country_market, country_share_of_world_market): - return index_weight_value * index_share_of_country_market * country_share_of_world_market - - -def change_in_listings(start_listings, end_listings): - return end_listings - start_listings - - -def percentage_change(start_value, end_value): - require_positive("start_value", start_value) - return end_value / start_value - 1 - - -def cagr(beginning_value, ending_value, years): - require_positive("beginning_value", beginning_value) - require_positive("years", years) - return (ending_value / beginning_value) ** (1 / years) - 1 diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/option_pools.py b/skills/finance-modeling-kernel/finance-modeling-kernel/option_pools.py deleted file mode 100644 index e593de1a..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/option_pools.py +++ /dev/null @@ -1,22 +0,0 @@ -def investor_friendly_option_pool(existing_shares, investor_target_ownership, target_option_pool): - total_post_money_shares = existing_shares / (1 - investor_target_ownership - target_option_pool) - investor_shares = investor_target_ownership * total_post_money_shares - option_pool_shares = target_option_pool * total_post_money_shares - existing_holder_ownership = existing_shares / total_post_money_shares - return { - "total_post_money_shares": total_post_money_shares, - "investor_shares": investor_shares, - "option_pool_shares": option_pool_shares, - "existing_holder_ownership": existing_holder_ownership, - } - - -def founder_friendly_option_pool(existing_shares, investor_shares, target_option_pool): - total_post_pool_shares = (existing_shares + investor_shares) / (1 - target_option_pool) - option_pool_shares = target_option_pool * total_post_pool_shares - investor_ownership_final = investor_shares / total_post_pool_shares - return { - "total_post_pool_shares": total_post_pool_shares, - "option_pool_shares": option_pool_shares, - "investor_ownership_final": investor_ownership_final, - } diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py b/skills/finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py deleted file mode 100644 index 2906dad5..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/preferred_stock.py +++ /dev/null @@ -1,19 +0,0 @@ -def liquidation_preference(investment, liquidation_multiple=1, accrued_dividends=0): - return investment * liquidation_multiple + accrued_dividends - - -def nonparticipating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership): - return max(liquidation_preference_value, as_converted_ownership * exit_value) - - -def participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences): - if exit_value <= total_preferences: - return min(exit_value, liquidation_preference_value) - return liquidation_preference_value + as_converted_ownership * (exit_value - total_preferences) - - -def capped_participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences, cap_multiple, investment): - uncapped = participating_preferred_payoff(exit_value, liquidation_preference_value, as_converted_ownership, total_preferences) - capped = min(uncapped, cap_multiple * investment) - converted = as_converted_ownership * exit_value - return max(capped, converted) diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/returns.py b/skills/finance-modeling-kernel/finance-modeling-kernel/returns.py deleted file mode 100644 index 7e925a81..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/returns.py +++ /dev/null @@ -1,48 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def realized_return(price_start, price_end, dividend=0): - require_positive("price_start", price_start) - return (price_end - price_start + dividend) / price_start - - -def expected_return(returns, probabilities): - require_same_length("returns", returns, "probabilities", probabilities) - return sum(probability * return_value for return_value, probability in zip(returns, probabilities)) - - -def variance(returns, probabilities): - mean = expected_return(returns, probabilities) - return sum(probability * (return_value - mean) ** 2 for return_value, probability in zip(returns, probabilities)) - - -def standard_deviation(returns, probabilities): - return sqrt(variance(returns, probabilities)) - - -def historical_average_return(returns): - require_positive("number of returns", len(returns)) - return sum(returns) / len(returns) - - -def portfolio_expected_return(weights, expected_returns): - require_same_length("weights", weights, "expected_returns", expected_returns) - return sum(weight * expected_return_value for weight, expected_return_value in zip(weights, expected_returns)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/risk.py b/skills/finance-modeling-kernel/finance-modeling-kernel/risk.py deleted file mode 100644 index bf065db7..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/risk.py +++ /dev/null @@ -1,41 +0,0 @@ -from math import sqrt -from validation import require_positive, require_same_length - - -def portfolio_variance(weights, covariance_matrix): - rows = len(covariance_matrix) - require_same_length("weights", weights, "covariance_matrix rows", covariance_matrix) - for row in covariance_matrix: - require_same_length("weights", weights, "covariance_matrix row", row) - return sum(weights[i] * weights[j] * covariance_matrix[i][j] for i in range(rows) for j in range(rows)) - - -def covariance(series_a, series_b): - require_same_length("series_a", series_a, "series_b", series_b) - require_positive("number of observations", len(series_a)) - mean_a = sum(series_a) / len(series_a) - mean_b = sum(series_b) / len(series_b) - return sum((a - mean_a) * (b - mean_b) for a, b in zip(series_a, series_b)) / len(series_a) - - -def correlation(series_a, series_b): - cov = covariance(series_a, series_b) - var_a = covariance(series_a, series_a) - var_b = covariance(series_b, series_b) - require_positive("variance of series_a", var_a) - require_positive("variance of series_b", var_b) - return cov / sqrt(var_a * var_b) - - -def beta(asset_returns, market_returns): - market_variance = covariance(market_returns, market_returns) - require_positive("market variance", market_variance) - return covariance(asset_returns, market_returns) / market_variance - - -def estimate_beta_regression(asset_returns, market_returns, risk_free_rates): - require_same_length("asset_returns", asset_returns, "market_returns", market_returns) - require_same_length("asset_returns", asset_returns, "risk_free_rates", risk_free_rates) - excess_asset = [asset - risk_free for asset, risk_free in zip(asset_returns, risk_free_rates)] - excess_market = [market - risk_free for market, risk_free in zip(market_returns, risk_free_rates)] - return beta(excess_asset, excess_market) diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/safes.py b/skills/finance-modeling-kernel/finance-modeling-kernel/safes.py deleted file mode 100644 index b8fcc474..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/safes.py +++ /dev/null @@ -1,15 +0,0 @@ -from validation import require_positive - - -def safe_conversion_price(discount_price, cap_price): - return min(discount_price, cap_price) - - -def safe_shares(investment_amount, conversion_price): - require_positive("conversion_price", conversion_price) - return investment_amount / conversion_price - - -def post_money_safe_ownership(investment_amount, post_money_valuation_cap): - require_positive("post_money_valuation_cap", post_money_valuation_cap) - return investment_amount / post_money_valuation_cap diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/time_value.py b/skills/finance-modeling-kernel/finance-modeling-kernel/time_value.py deleted file mode 100644 index 6d7850ba..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/time_value.py +++ /dev/null @@ -1,42 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth, require_same_length - - -def future_value(cash_flow, rate, periods): - return cash_flow * (1 + rate) ** periods - - -def present_value(cash_flow, rate, periods): - return cash_flow / (1 + rate) ** periods - - -def present_value_stream(cash_flows, rate): - return sum(present_value(cash_flow, rate, period) for period, cash_flow in enumerate(cash_flows, start=1)) - - -def present_value_with_spot_rates(cash_flows, spot_rates): - require_same_length("cash_flows", cash_flows, "spot_rates", spot_rates) - return sum(present_value(cash_flow, spot_rate, period) for period, (cash_flow, spot_rate) in enumerate(zip(cash_flows, spot_rates), start=1)) - - -def annuity_pv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * (1 - (1 + rate) ** (-periods)) / rate - - -def annuity_fv(payment, rate, periods): - require_positive("periods", periods) - if rate == 0: - return payment * periods - return payment * ((1 + rate) ** periods - 1) / rate - - -def perpetuity_pv(payment, rate): - require_positive("rate", rate) - return payment / rate - - -def growing_perpetuity_pv(next_payment, rate, growth_rate): - require_rate_greater_than_growth(rate, growth_rate) - return next_payment / (rate - growth_rate) diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/validation.py b/skills/finance-modeling-kernel/finance-modeling-kernel/validation.py deleted file mode 100644 index a94535ec..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/validation.py +++ /dev/null @@ -1,33 +0,0 @@ -class FinanceValidationError(ValueError): - """Raised when a finance formula cannot be applied safely.""" - - -def require_positive(name, value): - if value <= 0: - raise FinanceValidationError(f"{name} must be positive.") - return value - - -def require_nonnegative(name, value): - if value < 0: - raise FinanceValidationError(f"{name} must be nonnegative.") - return value - - -def require_rate_greater_than_growth(rate, growth_rate, rate_name="rate"): - if rate <= growth_rate: - raise FinanceValidationError(f"{rate_name} must be greater than growth rate.") - - -def require_same_length(name_a, values_a, name_b, values_b): - if len(values_a) != len(values_b): - raise FinanceValidationError(f"{name_a} and {name_b} must have the same length.") - - -def warn_if(condition, message, warnings=None): - if not condition: - return warnings if warnings is not None else [] - if warnings is None: - warnings = [] - warnings.append(message) - return warnings diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/valuation.py b/skills/finance-modeling-kernel/finance-modeling-kernel/valuation.py deleted file mode 100644 index 5c97d94a..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/valuation.py +++ /dev/null @@ -1,55 +0,0 @@ -from validation import require_positive, require_rate_greater_than_growth - - -def value_project_dcf(cash_flows, discount_rate, initial_investment): - return -initial_investment + sum(cash_flow / (1 + discount_rate) ** period for period, cash_flow in enumerate(cash_flows, start=1)) - - -def value_company_dcf(free_cash_flows, wacc, terminal_value): - return sum(fcf / (1 + wacc) ** period for period, fcf in enumerate(free_cash_flows, start=1)) + terminal_value / (1 + wacc) ** len(free_cash_flows) - - -def calculate_terminal_value_gordon(fcf_next, wacc, growth_rate): - require_rate_greater_than_growth(wacc, growth_rate, "wacc") - return fcf_next / (wacc - growth_rate) - - -def calculate_terminal_value_exit_multiple(metric, multiple): - return metric * multiple - - -def bridge_enterprise_to_equity_value(enterprise_value, debt=0, cash=0, preferred_stock=0, minority_interest=0, nonoperating_assets=0): - return enterprise_value - debt - preferred_stock - minority_interest + cash + nonoperating_assets - - -def calculate_price_per_share(equity_value, diluted_shares): - require_positive("diluted_shares", diluted_shares) - return equity_value / diluted_shares - - -def run_comparable_company_valuation(company_metric, comparable_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in comparable_multiples] - - -def run_precedent_transaction_valuation(company_metric, transaction_multiples): - return [calculate_implied_value(company_metric, multiple) for multiple in transaction_multiples] - - -def calculate_implied_multiple(value, metric): - require_positive("metric", metric) - return value / metric - - -def calculate_implied_value(metric, multiple): - return metric * multiple - - -def run_sensitivity_table(inputs, output_metric): - rows = [] - for case_name, case_inputs in inputs.items(): - rows.append({"case": case_name, "value": output_metric(**case_inputs)}) - return rows - - -def run_scenario_analysis(base_case, upside_case, downside_case): - return {"base": base_case, "upside": upside_case, "downside": downside_case} diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/vc_method.py b/skills/finance-modeling-kernel/finance-modeling-kernel/vc_method.py deleted file mode 100644 index 77d56314..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/vc_method.py +++ /dev/null @@ -1,57 +0,0 @@ -from validation import require_positive - - -def burn_rate(monthly_expenses, monthly_cash_receipts=0): - return monthly_expenses - monthly_cash_receipts - - -def runway(cash_balance, monthly_net_burn): - require_positive("monthly_net_burn", monthly_net_burn) - return cash_balance / monthly_net_burn - - -def vc_target_multiple(required_return, holding_period, probability_success): - require_positive("probability_success", probability_success) - return (1 + required_return) ** holding_period / probability_success - - -def vc_present_value(successful_exit_value, probability_success, required_return, holding_period): - return successful_exit_value * probability_success / (1 + required_return) ** holding_period - - -def vc_total_valuation(successful_exit_value, retention, target_multiple): - require_positive("target_multiple", target_multiple) - return successful_exit_value * retention / target_multiple - - -def vc_partial_valuation(proposed_ownership, total_valuation): - return proposed_ownership * total_valuation - - -def vc_required_ownership(required_investment, total_valuation): - require_positive("total_valuation", total_valuation) - return required_investment / total_valuation - - -def post_money(investment, ownership): - require_positive("ownership", ownership) - return investment / ownership - - -def pre_money(post_money_value, investment): - return post_money_value - investment - - -def price_per_share(pre_money_value, fully_diluted_pre_money_shares): - require_positive("fully_diluted_pre_money_shares", fully_diluted_pre_money_shares) - return pre_money_value / fully_diluted_pre_money_shares - - -def new_shares(investment, price_per_share_value): - require_positive("price_per_share", price_per_share_value) - return investment / price_per_share_value - - -def ownership(shares, total_shares): - require_positive("total_shares", total_shares) - return shares / total_shares diff --git a/skills/finance-modeling-kernel/finance-modeling-kernel/wacc.py b/skills/finance-modeling-kernel/finance-modeling-kernel/wacc.py deleted file mode 100644 index b147c830..00000000 --- a/skills/finance-modeling-kernel/finance-modeling-kernel/wacc.py +++ /dev/null @@ -1,9 +0,0 @@ -from validation import require_positive - - -def wacc(equity_value, debt_value, cost_of_equity, cost_of_debt, tax_rate): - total_value = equity_value + debt_value - require_positive("debt plus equity", total_value) - equity_weight = equity_value / total_value - debt_weight = debt_value / total_value - return equity_weight * cost_of_equity + debt_weight * (1 - tax_rate) * cost_of_debt diff --git a/skills/finance-modeling-kernel/productize.json b/skills/finance-modeling-kernel/productize.json deleted file mode 100644 index 04defde2..00000000 --- a/skills/finance-modeling-kernel/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Finance Modeling Kernel", - "category": "Finance", - "lifecycle": "Measure", - "tags": [ - "finance-modeling-kernel", - "finance-formulas", - "validation", - "dcf", - "npv", - "wacc", - "capm", - "vc-method", - "cap-table", - "preferred-stock", - "option-pools", - "market-context", - "finance", - "modeling" - ], - "use_when": "Use when any Productize Finance skill needs exact formulas, input normalization, assumption checks, result validation, units, warnings, or reusable calculation functions.", - "do_not_use_when": "Do not use as the user-facing valuation artifact when the user needs a decision, recommendation, or deal memo; route those requests to valuation-and-deal-pricing or the relevant finance engine.", - "output_artifact": "Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings", - "routing_signals": [ - "finance-formula", - "finance-calculation-engine", - "validate-finance-math", - "exact-formula", - "units-check", - "cash-flows-at-different-dates", - "finance-guardrails", - "finance-modeling-kernel", - "finance", - "modeling", - "kernel", - "shared", - "productize" - ], - "framework_fit": "Best as the shared math and validation layer underneath valuation, DCF, WACC, capital-structure, VC deal, and market-context work.", - "failure_modes": [ - "Lets a finance skill use a formula without checking preconditions such as r greater than g or positive denominator.", - "Compares cash flows at different dates without discounting or compounding.", - "Returns a number without units, timing, assumptions, or warnings.", - "Treats IRR, payback, or multiples as final truth instead of supporting evidence." - ], - "examples": [ - { - "prompt": "Use $finance-modeling-kernel to validate this DCF calculation and flag formula issues before we use it in a valuation memo.", - "expected_artifact": "Validated finance calculation with inputs, assumptions, formula, calculation, result, interpretation, and warnings" - } - ] -} diff --git a/skills/financial-markets-context/SKILL.md b/skills/financial-markets-context/SKILL.md deleted file mode 100644 index fdcfcb97..00000000 --- a/skills/financial-markets-context/SKILL.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -name: financial-markets-context -description: >- - Productize Finance context skill for market capitalization, market weights, index - concentration, listed-firm trends, public-company comparables, sector shifts, and - CAPM market-portfolio assumptions. ---- - - - -# Financial Markets Context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `financial-markets-context` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings - -## Purpose - -Market context skill. Use it to interpret public-market facts, index concentration, -listed-firm trends, market capitalization, comparable-company assumptions, sector -shifts, and market portfolio assumptions in CAPM. - -## Core Formulas - -- `Market Cap_i = Share Price_i * Shares Outstanding_i` -- `Weight_i = Market Cap_i / Total Market Cap` -- `Index Weight_i = Market Cap_i / sum(Market Cap of All Index Constituents)` -- `Global Weight_i = index weight * index share of country market * country share of world market` -- `Change in Listings = Listings_End - Listings_Start` -- `% Change = (End / Start - 1) * 100` -- `CAGR = (Ending Value / Beginning Value)^(1 / Years) - 1` - -## Interpretation Rules - -- Fewer listed firms does not necessarily mean a smaller equity market. -- Market capitalization can rise even if listings fall. -- This can happen because public firms become larger, smaller firms delist, and mergers concentrate value. -- Index concentration matters because the CAPM market portfolio is value-weighted. -- Public comparables may be biased if the target is much smaller, less mature, less profitable, or in a different sector. -- Sector composition changes over time, so historical index returns may reflect sector shifts, not only broad economic growth. - -## Required Validation - -- Warn if equal weighting is confused with value weighting. -- Warn if index concentration is ignored. -- Warn if public comparables are used for a startup without maturity adjustments. -- Warn if global market assumptions use only one domestic index. -- Warn if stale market weights are used. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Separate market fact, valuation implication, and comparability risk. diff --git a/skills/financial-markets-context/SKILL.md.tmpl b/skills/financial-markets-context/SKILL.md.tmpl deleted file mode 100644 index 3269b869..00000000 --- a/skills/financial-markets-context/SKILL.md.tmpl +++ /dev/null @@ -1,49 +0,0 @@ ---- -name: financial-markets-context -description: >- - Productize Finance context skill for market capitalization, market weights, index - concentration, listed-firm trends, public-company comparables, sector shifts, and - CAPM market-portfolio assumptions. ---- - -# Financial Markets Context - -{{PRODUCTIZE_PREAMBLE}} - -## Purpose - -Market context skill. Use it to interpret public-market facts, index concentration, -listed-firm trends, market capitalization, comparable-company assumptions, sector -shifts, and market portfolio assumptions in CAPM. - -## Core Formulas - -- `Market Cap_i = Share Price_i * Shares Outstanding_i` -- `Weight_i = Market Cap_i / Total Market Cap` -- `Index Weight_i = Market Cap_i / sum(Market Cap of All Index Constituents)` -- `Global Weight_i = index weight * index share of country market * country share of world market` -- `Change in Listings = Listings_End - Listings_Start` -- `% Change = (End / Start - 1) * 100` -- `CAGR = (Ending Value / Beginning Value)^(1 / Years) - 1` - -## Interpretation Rules - -- Fewer listed firms does not necessarily mean a smaller equity market. -- Market capitalization can rise even if listings fall. -- This can happen because public firms become larger, smaller firms delist, and mergers concentrate value. -- Index concentration matters because the CAPM market portfolio is value-weighted. -- Public comparables may be biased if the target is much smaller, less mature, less profitable, or in a different sector. -- Sector composition changes over time, so historical index returns may reflect sector shifts, not only broad economic growth. - -## Required Validation - -- Warn if equal weighting is confused with value weighting. -- Warn if index concentration is ignored. -- Warn if public comparables are used for a startup without maturity adjustments. -- Warn if global market assumptions use only one domestic index. -- Warn if stale market weights are used. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Separate market fact, valuation implication, and comparability risk. diff --git a/skills/financial-markets-context/agents/openai.yaml b/skills/financial-markets-context/agents/openai.yaml deleted file mode 100644 index 9946e751..00000000 --- a/skills/financial-markets-context/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Financial Markets Context" - short_description: "Productize Finance context skill for market capitalization, market weights, index concentration, listed-firm trends,..." - brand_color: "#0369A1" - default_prompt: "Use $financial-markets-context with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/financial-markets-context/productize.json b/skills/financial-markets-context/productize.json deleted file mode 100644 index d1962250..00000000 --- a/skills/financial-markets-context/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Financial Markets Context", - "category": "Finance", - "lifecycle": "Measure", - "tags": [ - "financial-markets-context", - "market-cap", - "market-weight", - "index-weight", - "index-concentration", - "listed-firms", - "public-comparables", - "sector-shifts", - "capm-market-portfolio", - "financial", - "markets", - "context", - "finance", - "productize" - ], - "use_when": "Use when explaining market-cap concentration, index weights, listed-firm trends, public-company comparables, sector shifts, or CAPM market-portfolio assumptions.", - "do_not_use_when": "Do not use as a full valuation skill unless the user primarily needs market context or comparable-company assumption checks.", - "output_artifact": "Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings", - "routing_signals": [ - "market-capitalization", - "market-cap", - "index-weight", - "index-concentration", - "market-portfolio", - "public-comparables", - "listed-firms", - "sector-shifts", - "global-market-weight", - "financial-markets-context", - "financial", - "markets", - "context", - "finance" - ], - "framework_fit": "Best when the user needs public-market interpretation or comparability discipline before using market data in valuation or CAPM.", - "failure_modes": [ - "Produces Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings without tying recommendations to the user's Measure stage, evidence, and decision pressure.", - "Treats Financial Markets Context as generic Finance advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Financial Markets Context when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $financial-markets-context to turn this market-capitalization context into a decision-ready Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings.", - "expected_artifact": "Financial Markets Context calculation memo with formulas, assumptions, result, interpretation, and warnings" - } - ] -} diff --git a/skills/fix-reviews/SKILL.md b/skills/fix-reviews/SKILL.md new file mode 100644 index 00000000..e779f57e --- /dev/null +++ b/skills/fix-reviews/SKILL.md @@ -0,0 +1,50 @@ +--- +name: fix-reviews +description: Executes provider-agnostic PR review remediation using existing review round files under .productize/tasks//reviews-NNN/. Use when resolving batched review issues, updating issue markdown files, implementing fixes, and verifying the result. Do not use for PRD task execution, review export/fetch, or generic coding tasks without review issue files. +--- + +# Fix Reviews + +Execute the review remediation workflow in a strict sequence. The review files already exist and define the full scope for the run. + +## Required Inputs + +- The scoped issue files listed in ``. +- The PRD review round directory and issue-file frontmatter. +- The repository verification workflow required by `final-verify`. + +## Workflow + +1. Gather round context. + - Read the scoped issue file frontmatter to understand the provider, round number, and issue status/severity. If multiple issue files are in scope, verify their `provider`, `pr`, `round`, and `round_created_at` values agree. + - Read `` to identify the PRD name, review round, code files in scope, and conditional flags such as auto-commit. + +2. Read and triage the scoped issue files. + - Read every listed issue file completely before editing code. + - Update each issue file frontmatter `status` from `pending` to `valid` or `invalid`. + - Record concrete technical reasoning in `## Triage`: state why the issue is valid or invalid, identify the root cause if valid, and outline the intended fix approach. + +3. Fix valid issues completely. + - Fix issues in severity order: critical first, then high, medium, low. This ensures the most impactful fixes land even if the batch is interrupted. + - Implement production-quality fixes for every `valid` issue in scope. + - Add or update tests when behavior changes or regressions are possible. Test file edits are always in scope when they validate a fix. + - Keep code changes constrained to the files listed in `` code files. If a fix absolutely requires touching a file not listed there, limit the change to the minimum needed and document why in the issue file's `## Triage` section. + - Do not refactor, clean up, or improve code that is unrelated to the issues being fixed. + +4. Close out issue files correctly. + - For a `valid` issue, set frontmatter `status: resolved` only after the code and verification are done. + - For an `invalid` issue, document why it is invalid and then set frontmatter `status: resolved` once the analysis is complete. + +5. Verify before completion. + - Use `final-verify` before any completion claim or automatic commit. + - Run the repositoryโ€™s real verification commands; do not stop at partial checks. + - If verification fails, fix the failing checks in the code you changed. Do not revert your fixes to pass verification -- find the root cause of the failure and address it. If the failure is in pre-existing code unrelated to your changes, document it in the relevant issue fileโ€™s `## Triage` section and proceed. If two fixes conflict with each other and verification cannot pass after two attempts, document the conflict in both issue files and report the situation rather than looping indefinitely. + - If all issues in the batch are invalid and no code was changed, skip the commit step entirely -- do not create an empty commit. Still run verification to confirm no regressions. + - Leave the diff ready for manual review unless `` shows "Automatic commits: enabled". + +## Critical Rules + +- Do not fetch or export reviews inside this workflow. `productize reviews fetch` already produced the round files. +- Do not call provider-specific scripts or `gh` mutations. Productize resolves provider threads after the batch succeeds. +- Do not modify issue files outside the scoped batch. +- Do not mark an issue `resolved` before the underlying work and verification are actually complete. diff --git a/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md b/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md deleted file mode 100644 index 0fadbc11..00000000 --- a/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md +++ /dev/null @@ -1,422 +0,0 @@ ---- -name: fragmented-user-research-synthesis-into-coherent-insights -description: >- - Fragmented user research synthesis into coherent insights. Use when the user needs a product - workflow for user research related to fragmented user research synthesis into coherent - insights. Trigger terms: user-research, synthesis, insights. ---- - - - -# Fragmented user research synthesis into coherent insights - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `fragmented-user-research-synthesis-into-coherent-insights` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Fragmented user research synthesis into coherent insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{RESEARCH_INPUTS}} -- {{PRODUCT_CONTEXT}} -- {{DESIGN_QUESTIONS}} -- {{CURRENT_ASSUMPTIONS}} -- {{BUSINESS_GOALS}} - - -GOAL -Produce a high-quality deliverable for: Fragmented user research synthesis into coherent insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Synthesize fragmented research inputs into coherent, evidence-based insights that inform design and product decisions. -- Use the provided inputs: -- `{{RESEARCH_INPUTS}}` -- `{{PRODUCT_CONTEXT}}` -- `{{DESIGN_QUESTIONS}}` -- `{{CURRENT_ASSUMPTIONS}}` -- `{{BUSINESS_GOALS}}` -- Perform synthesis rigorously: -- Inventory and assess source quality/coverage. -- Extract coded observations (quotes, behaviors, themes, segment/context metadata). -- Identify cross-source patterns and contradictions. -- Assign confidence levels with explicit rationale. -- Map insights to JTBD and user-needs hierarchy. -- Link insights directly to design questions and actionable recommendations. -- Identify research gaps, unresolved assumptions, and prioritized follow-up research. -- Keep evidence traceable, avoid over-generalization, and state assumptions/uncertainties explicitly. - -FORMAT -Return exactly this structure: - - - -**Data Sources Summary:** -- User interviews: [X participants] covering [topics, user segments, dates] -- Support tickets: [Y tickets] from [date range] about [primary themes] -- NPS feedback: [Z responses] with [average score] discussing [key topics] -- Usage analytics: [data range, key metrics, user actions analyzed] -- Feature requests: [count] requests across [platforms/sources] -- Usability tests: [sessions count] testing [specific flows or features] -- Survey data: [respondents count] on [topics covered] -- Anecdotal feedback: [source count] from [stakeholders, channels] -- Session recordings: [count] sessions showing [behaviors] -- Other sources: [specify any additional data] - -**Data Quality Assessment:** -- Time range: [how recent is this data?] -- User segment coverage: [which personas/segments are represented?] -- Sample size adequacy: [sufficient for confidence in findings?] -- Potential bias: [what perspectives might be over/under-represented?] -- Data completeness: [what's missing or sparse?] - - - - -**Insight Statement:** -[One clear, specific sentence stating what you learned about users] - -**Evidence:** -- User interviews: "[verbatim quote]" (Participant X, [segment]) -- Support tickets: [Y tickets] report "[specific issue]" with keywords: [terms] -- NPS feedback: "[example comment]" (common theme in Z% of detractor responses) -- Analytics data: [X% of users] exhibit [specific behavior], [frequency/context] -- Additional evidence: [any other supporting data points] - -**Confidence Level:** High / Medium / Low -**Rationale for Confidence:** [Why you assigned this confidence level] - -**User Segments Affected:** -- [Segment 1]: [how this manifests for them] -- [Segment 2]: [how this manifests for them] - -**Jobs-to-be-Done Connection:** -[Which job is this insight related to? How does it help or hinder job completion?] - -**Design Implications:** -- Consider: [specific design approach this suggests] -- Avoid: [what this insight argues against] -- Prioritize: [which aspect of the experience to focus on] -- Measure: [how to validate design addressed this insight] - -**Related Patterns:** -[Which other insights connect to this? How do they reinforce or complicate each other?] - -**Business Impact:** -[How does addressing this insight connect to business goals or metrics?] - - - -[Repeat the full structure for 5-10 key insights, maintaining consistent depth and evidence rigor] - - - -[Continue for all major insights...] - - - - -**Conflict 1:** -- Signal A: [what one source or segment indicates] -- Signal B: [what contradicts this] -- Possible explanations: - * [Explanation 1: e.g., different user segments with different needs] - * [Explanation 2: e.g., stated preference vs. actual behavior] - * [Explanation 3: e.g., context-dependent variation] -- Recommended resolution: [What research or analysis would clarify this?] -- Design strategy given conflict: [How to proceed despite uncertainty?] - -**Conflict 2:** -[Repeat structure for each major contradiction in the data] - -**Synthesis:** -[What do these conflicts reveal about user diversity, product complexity, or research gaps?] - - - -**Question 1:** [Restate the first design question] -- **Answer based on research:** [What the data tells you] -- **Supporting insights:** [Which insights from above inform this answer] -- **Confidence level:** High / Medium / Low -- **Caveats and limitations:** [What qualifies or nuances this answer] -- **What we still don't know:** [Gaps specific to this question] -- **Recommended action:** [What to design/test/research next] - -**Question 2:** [Restate the second design question] -[Repeat structure for each design question provided] - -**New Questions Surfaced:** -[Design questions that emerged from the research but weren't originally asked] - - - - -**Must-Have Needs (Strong Evidence, High Impact):** -1. [Need 1]: [description] - - Evidence: [cross-source validation] - - If unmet: [severe user/business consequence] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat structure for 3-5 critical needs] - - - -**Should-Have Needs (Moderate Evidence, Meaningful Impact):** -1. [Need 1]: [description] - - Evidence: [validation from 1-2 strong sources] - - If unmet: [moderate user friction or business impact] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat for 5-8 important needs] - - - -**Nice-to-Have Needs (Weak Signal, Low/Uncertain Impact):** -1. [Need 1]: [description] - - Evidence: [limited mentions or single source] - - Potential value: [why this might matter despite weak signal] - - Validation needed: [how to test if this is actually important] - -2. [Need 2]: [description] - [Repeat for 3-5 nice-to-have needs] - - - -**Segment-Specific Needs:** -- [Segment A]: [unique needs not shared by other segments] -- [Segment B]: [unique needs not shared by other segments] -- [Universal needs]: [needs expressed across all segments] - - - - -**Current Workflows and Workarounds:** -[Describe how users actually accomplish tasks today, including inefficient or creative workarounds that reveal unmet needs] - -**Decision-Making Patterns:** -[How users make choices within the product, what information they seek, what causes hesitation or confidence] - -**Pain Point Triggers:** -[Specific circumstances, contexts, or actions that consistently lead to user frustration] - -**Success Patterns:** -[When and how users successfully achieve their goals, what enables their success] - -**Usage Context and Frequency:** -[When, where, why, and how often users engage with the product or specific features] - -**Adoption and Learning Patterns:** -[How users onboard themselves, what helps or hinders learning, common confusion points] - -**Abandonment and Recovery Patterns:** -[What causes users to give up, what brings them back, how they recover from errors] - -**Cross-Tool Workflows:** -[How users combine your product with other tools, what gaps force tool-switching] - - - -**Primary Functional Jobs:** -1. [Job]: When [situation], I want to [motivation], so I can [expected outcome] - - Evidence: [how research revealed this job] - - Current obstacles: [what prevents job completion] - - Success criteria: [how users define successful job completion] - -2. [Job]: [Repeat structure for 3-5 primary jobs] - -**Emotional Jobs:** -- [Feel]: [emotion users want to feel, e.g., "feel confident in my decisions"] -- [Avoid]: [emotion users want to avoid, e.g., "avoid feeling overwhelmed"] -- Evidence: [quotes, observations, sentiment indicators] - -**Social Jobs:** -- [Perception]: [how users want to be seen, e.g., "be perceived as data-driven"] -- [Context]: [social situations where product use matters] -- Evidence: [research indicators of social motivations] - -**Related Jobs in the Consumption Chain:** -- Before main job: [how users discover, evaluate, and choose the product] -- After main job: [how users share, report, or build on outcomes] -- Maintenance jobs: [ongoing tasks to keep getting value] - - - - -**Critical Unknowns (Blocking Design Decisions):** -1. [Question]: [why this matters for design] -2. [Question]: [why this matters for design] -3. [Question]: [why this matters for design] - -**Important Unknowns (Would Significantly Inform Design):** -1. [Question]: [how this would help] -2. [Question]: [how this would help] - -**Curiosities (Interesting But Not Urgent):** -1. [Question]: [potential value] -2. [Question]: [potential value] - - - -**Research Activity 1:** -- **Method:** [interviews / usability testing / survey / analytics deep-dive / diary study / etc.] -- **Target participants:** [which user segments, how many, recruitment criteria] -- **Key questions to answer:** [specific questions this research would resolve] -- **Expected outcomes:** [what you'll learn and how it informs design] -- **Effort estimate:** [time and resources required] -- **Priority:** High / Medium / Low - [rationale] - -**Research Activity 2:** -[Repeat structure for 3-5 recommended research activities, prioritized by impact and urgency] - - - -**Design Assumptions:** -1. [Assumption about user behavior or preferences]: Currently [validated / unvalidated / contradicted] by research -2. [Assumption about priorities or needs]: Currently [status] -3. [Assumption about technical or business constraints]: Currently [status] - -**Team Assumptions:** -[Assumptions stakeholders or team members hold that aren't supported by dataโ€”list with gentle evidence-based reframing] - -**Testing Strategy:** -[How to quickly validate or invalidate the most critical assumptions through lightweight tests] - - - - -**Priority 1 Recommendations (Supported by High-Confidence Insights):** -1. [Specific design action]: [rationale tied to insight X, Y, Z] - - Expected impact: [user and business outcomes] - - Success metrics: [how to measure if this worked] - -2. [Specific design action]: [rationale tied to insights] - [Repeat for 3-5 top-priority recommendations] - -**Priority 2 Recommendations (Supported by Medium-Confidence Insights):** -1. [Specific design action]: [rationale] - [Repeat for 5-7 secondary recommendations] - -**Quick Wins (Low Effort, Clear User Value):** -1. [Specific design action]: [why this is easy and valuable] - [Repeat for 3-5 quick wins] - -**Strategic Bets (Lower Confidence, High Potential):** -1. [Specific design action]: [why worth exploring despite uncertainty] - - Validation approach: [how to test before full commitment] - [Repeat for 2-3 strategic bets] - -**Do Not Pursue:** -[Features, changes, or directions that research argues against, with rationale] - - - -**Executive Summary** - -**What We Learned:** -[2-3 sentences capturing the most important insights from the research] - -**User Needs Priority:** -Users critically need [top need], strongly want [second need], and would appreciate [third need]. The evidence is strongest for [insight area] and weakest for [insight area requiring validation]. - -**Key Behavioral Patterns:** -[1-2 sentences on how users actually behave vs. what we might have assumed] - -**Design Implications:** -The research strongly supports [recommended direction 1] and [recommended direction 2], while arguing against [current assumption or planned direction]. We should prioritize [specific user segment or job-to-be-done] because [evidence-based rationale]. - -**Critical Unknowns:** -We still need to understand [key gap 1] and [key gap 2] through [recommended research method]. - -**Recommended Next Steps:** -1. [Immediate action based on high-confidence insights] -2. [Design exploration for medium-confidence opportunities] -3. [Targeted research to fill critical gaps] - -**Business Impact:** -Addressing these insights is expected to improve [business metric] by [directional estimate] because [user behavior change expected]. - -[Total: 250-350 words] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Insights are not supported by cross-source evidence or confidence rationale. -- Contradictions are ignored or not addressed with a resolution approach. -- Recommendations are not prioritized or not linked to synthesized insights/business goals. -- Research gaps and assumption validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md.tmpl b/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md.tmpl deleted file mode 100644 index eef6b2b2..00000000 --- a/skills/fragmented-user-research-synthesis-into-coherent-insights/SKILL.md.tmpl +++ /dev/null @@ -1,363 +0,0 @@ ---- -name: fragmented-user-research-synthesis-into-coherent-insights -description: >- - Fragmented user research synthesis into coherent insights. Use when the user needs a product - workflow for user research related to fragmented user research synthesis into coherent - insights. Trigger terms: user-research, synthesis, insights. ---- -# Fragmented user research synthesis into coherent insights - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Fragmented user research synthesis into coherent insights**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{RESEARCH_INPUTS}} -- {{PRODUCT_CONTEXT}} -- {{DESIGN_QUESTIONS}} -- {{CURRENT_ASSUMPTIONS}} -- {{BUSINESS_GOALS}} - - -GOAL -Produce a high-quality deliverable for: Fragmented user research synthesis into coherent insights. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Synthesize fragmented research inputs into coherent, evidence-based insights that inform design and product decisions. -- Use the provided inputs: -- `{{RESEARCH_INPUTS}}` -- `{{PRODUCT_CONTEXT}}` -- `{{DESIGN_QUESTIONS}}` -- `{{CURRENT_ASSUMPTIONS}}` -- `{{BUSINESS_GOALS}}` -- Perform synthesis rigorously: -- Inventory and assess source quality/coverage. -- Extract coded observations (quotes, behaviors, themes, segment/context metadata). -- Identify cross-source patterns and contradictions. -- Assign confidence levels with explicit rationale. -- Map insights to JTBD and user-needs hierarchy. -- Link insights directly to design questions and actionable recommendations. -- Identify research gaps, unresolved assumptions, and prioritized follow-up research. -- Keep evidence traceable, avoid over-generalization, and state assumptions/uncertainties explicitly. - -FORMAT -Return exactly this structure: - - - -**Data Sources Summary:** -- User interviews: [X participants] covering [topics, user segments, dates] -- Support tickets: [Y tickets] from [date range] about [primary themes] -- NPS feedback: [Z responses] with [average score] discussing [key topics] -- Usage analytics: [data range, key metrics, user actions analyzed] -- Feature requests: [count] requests across [platforms/sources] -- Usability tests: [sessions count] testing [specific flows or features] -- Survey data: [respondents count] on [topics covered] -- Anecdotal feedback: [source count] from [stakeholders, channels] -- Session recordings: [count] sessions showing [behaviors] -- Other sources: [specify any additional data] - -**Data Quality Assessment:** -- Time range: [how recent is this data?] -- User segment coverage: [which personas/segments are represented?] -- Sample size adequacy: [sufficient for confidence in findings?] -- Potential bias: [what perspectives might be over/under-represented?] -- Data completeness: [what's missing or sparse?] - - - - -**Insight Statement:** -[One clear, specific sentence stating what you learned about users] - -**Evidence:** -- User interviews: "[verbatim quote]" (Participant X, [segment]) -- Support tickets: [Y tickets] report "[specific issue]" with keywords: [terms] -- NPS feedback: "[example comment]" (common theme in Z% of detractor responses) -- Analytics data: [X% of users] exhibit [specific behavior], [frequency/context] -- Additional evidence: [any other supporting data points] - -**Confidence Level:** High / Medium / Low -**Rationale for Confidence:** [Why you assigned this confidence level] - -**User Segments Affected:** -- [Segment 1]: [how this manifests for them] -- [Segment 2]: [how this manifests for them] - -**Jobs-to-be-Done Connection:** -[Which job is this insight related to? How does it help or hinder job completion?] - -**Design Implications:** -- Consider: [specific design approach this suggests] -- Avoid: [what this insight argues against] -- Prioritize: [which aspect of the experience to focus on] -- Measure: [how to validate design addressed this insight] - -**Related Patterns:** -[Which other insights connect to this? How do they reinforce or complicate each other?] - -**Business Impact:** -[How does addressing this insight connect to business goals or metrics?] - - - -[Repeat the full structure for 5-10 key insights, maintaining consistent depth and evidence rigor] - - - -[Continue for all major insights...] - - - - -**Conflict 1:** -- Signal A: [what one source or segment indicates] -- Signal B: [what contradicts this] -- Possible explanations: - * [Explanation 1: e.g., different user segments with different needs] - * [Explanation 2: e.g., stated preference vs. actual behavior] - * [Explanation 3: e.g., context-dependent variation] -- Recommended resolution: [What research or analysis would clarify this?] -- Design strategy given conflict: [How to proceed despite uncertainty?] - -**Conflict 2:** -[Repeat structure for each major contradiction in the data] - -**Synthesis:** -[What do these conflicts reveal about user diversity, product complexity, or research gaps?] - - - -**Question 1:** [Restate the first design question] -- **Answer based on research:** [What the data tells you] -- **Supporting insights:** [Which insights from above inform this answer] -- **Confidence level:** High / Medium / Low -- **Caveats and limitations:** [What qualifies or nuances this answer] -- **What we still don't know:** [Gaps specific to this question] -- **Recommended action:** [What to design/test/research next] - -**Question 2:** [Restate the second design question] -[Repeat structure for each design question provided] - -**New Questions Surfaced:** -[Design questions that emerged from the research but weren't originally asked] - - - - -**Must-Have Needs (Strong Evidence, High Impact):** -1. [Need 1]: [description] - - Evidence: [cross-source validation] - - If unmet: [severe user/business consequence] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat structure for 3-5 critical needs] - - - -**Should-Have Needs (Moderate Evidence, Meaningful Impact):** -1. [Need 1]: [description] - - Evidence: [validation from 1-2 strong sources] - - If unmet: [moderate user friction or business impact] - - Current state: [how well is this met today?] - -2. [Need 2]: [description] - [Repeat for 5-8 important needs] - - - -**Nice-to-Have Needs (Weak Signal, Low/Uncertain Impact):** -1. [Need 1]: [description] - - Evidence: [limited mentions or single source] - - Potential value: [why this might matter despite weak signal] - - Validation needed: [how to test if this is actually important] - -2. [Need 2]: [description] - [Repeat for 3-5 nice-to-have needs] - - - -**Segment-Specific Needs:** -- [Segment A]: [unique needs not shared by other segments] -- [Segment B]: [unique needs not shared by other segments] -- [Universal needs]: [needs expressed across all segments] - - - - -**Current Workflows and Workarounds:** -[Describe how users actually accomplish tasks today, including inefficient or creative workarounds that reveal unmet needs] - -**Decision-Making Patterns:** -[How users make choices within the product, what information they seek, what causes hesitation or confidence] - -**Pain Point Triggers:** -[Specific circumstances, contexts, or actions that consistently lead to user frustration] - -**Success Patterns:** -[When and how users successfully achieve their goals, what enables their success] - -**Usage Context and Frequency:** -[When, where, why, and how often users engage with the product or specific features] - -**Adoption and Learning Patterns:** -[How users onboard themselves, what helps or hinders learning, common confusion points] - -**Abandonment and Recovery Patterns:** -[What causes users to give up, what brings them back, how they recover from errors] - -**Cross-Tool Workflows:** -[How users combine your product with other tools, what gaps force tool-switching] - - - -**Primary Functional Jobs:** -1. [Job]: When [situation], I want to [motivation], so I can [expected outcome] - - Evidence: [how research revealed this job] - - Current obstacles: [what prevents job completion] - - Success criteria: [how users define successful job completion] - -2. [Job]: [Repeat structure for 3-5 primary jobs] - -**Emotional Jobs:** -- [Feel]: [emotion users want to feel, e.g., "feel confident in my decisions"] -- [Avoid]: [emotion users want to avoid, e.g., "avoid feeling overwhelmed"] -- Evidence: [quotes, observations, sentiment indicators] - -**Social Jobs:** -- [Perception]: [how users want to be seen, e.g., "be perceived as data-driven"] -- [Context]: [social situations where product use matters] -- Evidence: [research indicators of social motivations] - -**Related Jobs in the Consumption Chain:** -- Before main job: [how users discover, evaluate, and choose the product] -- After main job: [how users share, report, or build on outcomes] -- Maintenance jobs: [ongoing tasks to keep getting value] - - - - -**Critical Unknowns (Blocking Design Decisions):** -1. [Question]: [why this matters for design] -2. [Question]: [why this matters for design] -3. [Question]: [why this matters for design] - -**Important Unknowns (Would Significantly Inform Design):** -1. [Question]: [how this would help] -2. [Question]: [how this would help] - -**Curiosities (Interesting But Not Urgent):** -1. [Question]: [potential value] -2. [Question]: [potential value] - - - -**Research Activity 1:** -- **Method:** [interviews / usability testing / survey / analytics deep-dive / diary study / etc.] -- **Target participants:** [which user segments, how many, recruitment criteria] -- **Key questions to answer:** [specific questions this research would resolve] -- **Expected outcomes:** [what you'll learn and how it informs design] -- **Effort estimate:** [time and resources required] -- **Priority:** High / Medium / Low - [rationale] - -**Research Activity 2:** -[Repeat structure for 3-5 recommended research activities, prioritized by impact and urgency] - - - -**Design Assumptions:** -1. [Assumption about user behavior or preferences]: Currently [validated / unvalidated / contradicted] by research -2. [Assumption about priorities or needs]: Currently [status] -3. [Assumption about technical or business constraints]: Currently [status] - -**Team Assumptions:** -[Assumptions stakeholders or team members hold that aren't supported by dataโ€”list with gentle evidence-based reframing] - -**Testing Strategy:** -[How to quickly validate or invalidate the most critical assumptions through lightweight tests] - - - - -**Priority 1 Recommendations (Supported by High-Confidence Insights):** -1. [Specific design action]: [rationale tied to insight X, Y, Z] - - Expected impact: [user and business outcomes] - - Success metrics: [how to measure if this worked] - -2. [Specific design action]: [rationale tied to insights] - [Repeat for 3-5 top-priority recommendations] - -**Priority 2 Recommendations (Supported by Medium-Confidence Insights):** -1. [Specific design action]: [rationale] - [Repeat for 5-7 secondary recommendations] - -**Quick Wins (Low Effort, Clear User Value):** -1. [Specific design action]: [why this is easy and valuable] - [Repeat for 3-5 quick wins] - -**Strategic Bets (Lower Confidence, High Potential):** -1. [Specific design action]: [why worth exploring despite uncertainty] - - Validation approach: [how to test before full commitment] - [Repeat for 2-3 strategic bets] - -**Do Not Pursue:** -[Features, changes, or directions that research argues against, with rationale] - - - -**Executive Summary** - -**What We Learned:** -[2-3 sentences capturing the most important insights from the research] - -**User Needs Priority:** -Users critically need [top need], strongly want [second need], and would appreciate [third need]. The evidence is strongest for [insight area] and weakest for [insight area requiring validation]. - -**Key Behavioral Patterns:** -[1-2 sentences on how users actually behave vs. what we might have assumed] - -**Design Implications:** -The research strongly supports [recommended direction 1] and [recommended direction 2], while arguing against [current assumption or planned direction]. We should prioritize [specific user segment or job-to-be-done] because [evidence-based rationale]. - -**Critical Unknowns:** -We still need to understand [key gap 1] and [key gap 2] through [recommended research method]. - -**Recommended Next Steps:** -1. [Immediate action based on high-confidence insights] -2. [Design exploration for medium-confidence opportunities] -3. [Targeted research to fill critical gaps] - -**Business Impact:** -Addressing these insights is expected to improve [business metric] by [directional estimate] because [user behavior change expected]. - -[Total: 250-350 words] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Insights are not supported by cross-source evidence or confidence rationale. -- Contradictions are ignored or not addressed with a resolution approach. -- Recommendations are not prioritized or not linked to synthesized insights/business goals. -- Research gaps and assumption validation plan are missing or non-specific. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/fragmented-user-research-synthesis-into-coherent-insights/agents/openai.yaml b/skills/fragmented-user-research-synthesis-into-coherent-insights/agents/openai.yaml deleted file mode 100644 index 979bc9ba..00000000 --- a/skills/fragmented-user-research-synthesis-into-coherent-insights/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Fragmented user research synthesis into coherent insights" - short_description: "Fragmented user research synthesis into coherent insights. Use when the user needs a product workflow for user..." - brand_color: "#0D9488" - default_prompt: "Use $fragmented-user-research-synthesis-into-coherent-insights with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/fragmented-user-research-synthesis-into-coherent-insights/productize.json b/skills/fragmented-user-research-synthesis-into-coherent-insights/productize.json deleted file mode 100644 index 64438c3f..00000000 --- a/skills/fragmented-user-research-synthesis-into-coherent-insights/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Fragmented user research synthesis into coherent insights", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "fragmented-user-research-synthesis-into-coherent-insights", - "fragmented", - "research", - "synthesis", - "coherent", - "insights" - ], - "use_when": "Fragmented user research synthesis into coherent insights. Use when the user needs a product workflow for user research related to fragmented user research synthesis into coherent insights. Trigger terms: user-research, synthesis, insights.", - "do_not_use_when": "Do not use Fragmented user research synthesis into coherent insights when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "fragmented-user-research-synthesis-into-coherent-insights", - "fragmented", - "research", - "synthesis", - "coherent", - "insights" - ], - "framework_fit": "Fragmented user research synthesis into coherent insights fits Discovery work in the Discover lifecycle when the user needs Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Fragmented user research synthesis into coherent insights as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Fragmented user research synthesis into coherent insights when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $fragmented-user-research-synthesis-into-coherent-insights to turn this fragmented context into a decision-ready Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Fragmented user research synthesis into coherent insights research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/framework-application-to-product-challenges-from-user-input/SKILL.md b/skills/framework-application-to-product-challenges-from-user-input/SKILL.md deleted file mode 100644 index ac6f1c56..00000000 --- a/skills/framework-application-to-product-challenges-from-user-input/SKILL.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -name: framework-application-to-product-challenges-from-user-input -description: >- - Framework application to product challenges from user input. Use when the user needs a - product workflow for product strategy related to framework application to product challenges - from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching. ---- - - - -# Framework application to product challenges from user input - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `framework-application-to-product-challenges-from-user-input` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Framework application to product challenges from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRAMEWORK}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Framework application to product challenges from user input. -Success metric: -- Asks targeted questions when key context is missing. -- Applies the provided framework precisely to the userโ€™s situation. -- Produces actionable advice and a clear recommendation when sufficient context exists. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{FRAMEWORK}}` and `{{USER_INPUT}}`; if key context is missing, ask targeted questions first. -- Do not summarize the framework back to the user. -- When asking for more information, use `` tags only. -- When providing guidance, use `` tags only. -- When providing a final recommendation, use `` tags only. -- Keep advice specific and grounded in the userโ€™s context; avoid generic PM guidance. - -FORMAT -Return exactly this structure: - - -[Targeted questions needed to apply the framework] - - - -[Framework-applied guidance once sufficient context exists] - - - -[Final recommendation when enough context exists] - - -FAILURE -- Required tags are missing or malformed. -- Output includes framework summary instead of application. -- Advice is generic or not tied to the user input. -- Recommendation is provided without sufficient context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/framework-application-to-product-challenges-from-user-input/SKILL.md.tmpl b/skills/framework-application-to-product-challenges-from-user-input/SKILL.md.tmpl deleted file mode 100644 index 4f9754ee..00000000 --- a/skills/framework-application-to-product-challenges-from-user-input/SKILL.md.tmpl +++ /dev/null @@ -1,67 +0,0 @@ ---- -name: framework-application-to-product-challenges-from-user-input -description: >- - Framework application to product challenges from user input. Use when the user needs a - product workflow for product strategy related to framework application to product challenges - from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching. ---- -# Framework application to product challenges from user input - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Framework application to product challenges from user input**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{FRAMEWORK}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Framework application to product challenges from user input. -Success metric: -- Asks targeted questions when key context is missing. -- Applies the provided framework precisely to the userโ€™s situation. -- Produces actionable advice and a clear recommendation when sufficient context exists. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{FRAMEWORK}}` and `{{USER_INPUT}}`; if key context is missing, ask targeted questions first. -- Do not summarize the framework back to the user. -- When asking for more information, use `` tags only. -- When providing guidance, use `` tags only. -- When providing a final recommendation, use `` tags only. -- Keep advice specific and grounded in the userโ€™s context; avoid generic PM guidance. - -FORMAT -Return exactly this structure: - - -[Targeted questions needed to apply the framework] - - - -[Framework-applied guidance once sufficient context exists] - - - -[Final recommendation when enough context exists] - - -FAILURE -- Required tags are missing or malformed. -- Output includes framework summary instead of application. -- Advice is generic or not tied to the user input. -- Recommendation is provided without sufficient context. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/framework-application-to-product-challenges-from-user-input/agents/openai.yaml b/skills/framework-application-to-product-challenges-from-user-input/agents/openai.yaml deleted file mode 100644 index 1c9c3691..00000000 --- a/skills/framework-application-to-product-challenges-from-user-input/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Framework application to product challenges from user input" - short_description: "Framework application to product challenges from user input. Use when the user needs a product workflow for product..." - brand_color: "#059669" - default_prompt: "Use $framework-application-to-product-challenges-from-user-input with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/framework-application-to-product-challenges-from-user-input/productize.json b/skills/framework-application-to-product-challenges-from-user-input/productize.json deleted file mode 100644 index a5c707d8..00000000 --- a/skills/framework-application-to-product-challenges-from-user-input/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Framework application to product challenges from user input", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "framework-application-to-product-challenges-from-user-input", - "framework", - "application", - "challenges", - "input" - ], - "use_when": "Framework application to product challenges from user input. Use when the user needs a product workflow for product strategy related to framework application to product challenges from user input. Trigger terms: product-strategy, frameworks, decision-making, coaching.", - "do_not_use_when": "Do not use Framework application to product challenges from user input when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "framework-application-to-product-challenges-from-user-input", - "framework", - "application", - "challenges", - "input" - ], - "framework_fit": "Framework application to product challenges from user input fits Strategy work in the Strategize lifecycle when the user needs Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Framework application to product challenges from user input as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Framework application to product challenges from user input when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $framework-application-to-product-challenges-from-user-input to turn this framework context into a decision-ready Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Framework application to product challenges from user input strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/frontend-design/SKILL.md b/skills/frontend-design/SKILL.md deleted file mode 100644 index 7c052af4..00000000 --- a/skills/frontend-design/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: frontend-design -description: >- - Design implementation-ready frontend solutions with UX intent, component structure, - responsive behavior, accessibility, and handoff criteria. ---- - - - -# Frontend Design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `frontend-design` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to design frontend behavior and UI structure before or alongside implementation. - -## The Process - -### Step 1: Define UX objective - -Capture: -- user goal -- primary user flow -- success state and failure states - -### Step 2: Specify UI architecture - -Define: -- screen/layout structure -- component hierarchy -- state model (loading, empty, error, success) - -### Step 3: Specify design system decisions - -Set: -- typography and spacing rules -- color/contrast constraints -- interaction patterns - -### Step 4: Specify responsive and accessibility requirements - -Include: -- breakpoints and behavior changes -- keyboard navigation expectations -- ARIA/semantic requirements -- contrast and focus visibility requirements - -### Step 5: Define implementation handoff - -Provide: -- component list and props/state contract -- acceptance criteria -- verification checklist - -## Output Format - -```markdown -# [Feature Name] Frontend Design Spec - -## UX Objective -- User goal: -- Primary flow: -- Success/failure states: - -## UI Architecture -- Layout: -- Component hierarchy: -- State model: - -## Responsive Behavior -- Desktop: -- Tablet: -- Mobile: - -## Accessibility Requirements -- Keyboard: -- Semantics/ARIA: -- Contrast/focus: - -## Handoff -- Components to implement: -- Acceptance criteria: -- Verification checklist: -``` - -## Quality Bar - -- Design decisions must map to user goals -- Accessibility section is mandatory -- Handoff must be implementable without extra interpretation - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/frontend-design/SKILL.md.tmpl b/skills/frontend-design/SKILL.md.tmpl deleted file mode 100644 index 90238ecc..00000000 --- a/skills/frontend-design/SKILL.md.tmpl +++ /dev/null @@ -1,94 +0,0 @@ ---- -name: frontend-design -description: >- - Design implementation-ready frontend solutions with UX intent, component structure, - responsive behavior, accessibility, and handoff criteria. ---- -# Frontend Design - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to design frontend behavior and UI structure before or alongside implementation. - -## The Process - -### Step 1: Define UX objective - -Capture: -- user goal -- primary user flow -- success state and failure states - -### Step 2: Specify UI architecture - -Define: -- screen/layout structure -- component hierarchy -- state model (loading, empty, error, success) - -### Step 3: Specify design system decisions - -Set: -- typography and spacing rules -- color/contrast constraints -- interaction patterns - -### Step 4: Specify responsive and accessibility requirements - -Include: -- breakpoints and behavior changes -- keyboard navigation expectations -- ARIA/semantic requirements -- contrast and focus visibility requirements - -### Step 5: Define implementation handoff - -Provide: -- component list and props/state contract -- acceptance criteria -- verification checklist - -## Output Format - -```markdown -# [Feature Name] Frontend Design Spec - -## UX Objective -- User goal: -- Primary flow: -- Success/failure states: - -## UI Architecture -- Layout: -- Component hierarchy: -- State model: - -## Responsive Behavior -- Desktop: -- Tablet: -- Mobile: - -## Accessibility Requirements -- Keyboard: -- Semantics/ARIA: -- Contrast/focus: - -## Handoff -- Components to implement: -- Acceptance criteria: -- Verification checklist: -``` - -## Quality Bar - -- Design decisions must map to user goals -- Accessibility section is mandatory -- Handoff must be implementable without extra interpretation - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/frontend-design/agents/openai.yaml b/skills/frontend-design/agents/openai.yaml deleted file mode 100644 index b841a55d..00000000 --- a/skills/frontend-design/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Frontend Design" - short_description: "Design implementation-ready frontend solutions with UX intent, component structure, responsive behavior,..." - brand_color: "#DB2777" - default_prompt: "Use $frontend-design with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/frontend-design/productize.json b/skills/frontend-design/productize.json deleted file mode 100644 index d5886e0b..00000000 --- a/skills/frontend-design/productize.json +++ /dev/null @@ -1,44 +0,0 @@ -{ - "title": "Frontend Design", - "category": "Design", - "tags": [ - "frontend-architecture", - "ux-intent", - "component-structure", - "responsive-design", - "accessibility", - "handoff", - "frontend-design", - "frontend", - "design", - "technical", - "implementation", - "ready", - "solutions" - ], - "lifecycle": "Design", - "use_when": "Design implementation-ready frontend solutions with UX intent, component structure, responsive behavior, accessibility, and handoff criteria.", - "do_not_use_when": "Do not use Frontend Design when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "frontend-design", - "frontend", - "design", - "technical", - "implementation", - "ready", - "solutions" - ], - "framework_fit": "Frontend Design fits Design work in the Design lifecycle when the user needs Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Frontend Design as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Frontend Design when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $frontend-design to turn this frontend context into a decision-ready Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Frontend Design UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/future-product-opportunities-from-market-inflection-points/SKILL.md b/skills/future-product-opportunities-from-market-inflection-points/SKILL.md deleted file mode 100644 index 508e76c8..00000000 --- a/skills/future-product-opportunities-from-market-inflection-points/SKILL.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -name: future-product-opportunities-from-market-inflection-points -description: >- - Future product opportunities from market inflection points. Use when the user needs a - product workflow for product strategy related to future product opportunities from market - inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, - trends, product-vision. ---- - - - -# Future product opportunities from market inflection points - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `future-product-opportunities-from-market-inflection-points` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Future product opportunities from market inflection points**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_YEAR}} -- {{RESEARCH_TIMEFRAME}} - - -GOAL -Produce a high-quality deliverable for: Future product opportunities from market inflection points. -Success metric: -- Identifies concrete regulatory, technological, and belief inflection points within the stated timeframe. -- Connects converging trends to 3โ€“5 plausible future opportunities. -- Provides actionable challenges and timelines for each opportunity. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_YEAR}}` and `{{RESEARCH_TIMEFRAME}}`; if context is missing, state assumptions explicitly. -- List 3โ€“5 items per inflection category (regulatory, technological, belief). -- Provide 3โ€“5 converging trend sets that explicitly combine at least two categories. -- Provide 3โ€“5 future opportunities with concept, enabling trends, challenges, and timeline. -- Keep opportunities plausible within the specified research timeframe. - -FORMAT -Return exactly this structure: - - -1. Inflection Points: - a. Regulatory: - - [List 3โ€“5 significant regulatory changes] - b. Technological: - - [List 3โ€“5 important technological advancements] - c. Belief: - - [List 3โ€“5 notable shifts in societal attitudes or behaviors] - -2. Converging Trends: - - [Describe 3โ€“5 sets of converging trends, explaining how they intersect] - -3. Future Opportunities: - [For each opportunity (aim for 3โ€“5), include:] - a. Concept: [Brief description] - b. Enabling Trends: [List the key inflection points or converging trends] - c. Challenges: [Potential barriers or difficulties] - d. Timeline: [Estimated timeframe for realization] - -4. Conclusion: - [Summarize the most promising areas for innovation based on your analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any inflection category has fewer than 3 or more than 5 items. -- Converging trends do not combine multiple categories. -- Opportunities are missing required fields or outside the specified timeframe. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/future-product-opportunities-from-market-inflection-points/SKILL.md.tmpl b/skills/future-product-opportunities-from-market-inflection-points/SKILL.md.tmpl deleted file mode 100644 index 93f37321..00000000 --- a/skills/future-product-opportunities-from-market-inflection-points/SKILL.md.tmpl +++ /dev/null @@ -1,78 +0,0 @@ ---- -name: future-product-opportunities-from-market-inflection-points -description: >- - Future product opportunities from market inflection points. Use when the user needs a - product workflow for product strategy related to future product opportunities from market - inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, - trends, product-vision. ---- -# Future product opportunities from market inflection points - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Future product opportunities from market inflection points**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CURRENT_YEAR}} -- {{RESEARCH_TIMEFRAME}} - - -GOAL -Produce a high-quality deliverable for: Future product opportunities from market inflection points. -Success metric: -- Identifies concrete regulatory, technological, and belief inflection points within the stated timeframe. -- Connects converging trends to 3โ€“5 plausible future opportunities. -- Provides actionable challenges and timelines for each opportunity. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CURRENT_YEAR}}` and `{{RESEARCH_TIMEFRAME}}`; if context is missing, state assumptions explicitly. -- List 3โ€“5 items per inflection category (regulatory, technological, belief). -- Provide 3โ€“5 converging trend sets that explicitly combine at least two categories. -- Provide 3โ€“5 future opportunities with concept, enabling trends, challenges, and timeline. -- Keep opportunities plausible within the specified research timeframe. - -FORMAT -Return exactly this structure: - - -1. Inflection Points: - a. Regulatory: - - [List 3โ€“5 significant regulatory changes] - b. Technological: - - [List 3โ€“5 important technological advancements] - c. Belief: - - [List 3โ€“5 notable shifts in societal attitudes or behaviors] - -2. Converging Trends: - - [Describe 3โ€“5 sets of converging trends, explaining how they intersect] - -3. Future Opportunities: - [For each opportunity (aim for 3โ€“5), include:] - a. Concept: [Brief description] - b. Enabling Trends: [List the key inflection points or converging trends] - c. Challenges: [Potential barriers or difficulties] - d. Timeline: [Estimated timeframe for realization] - -4. Conclusion: - [Summarize the most promising areas for innovation based on your analysis] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any inflection category has fewer than 3 or more than 5 items. -- Converging trends do not combine multiple categories. -- Opportunities are missing required fields or outside the specified timeframe. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/future-product-opportunities-from-market-inflection-points/agents/openai.yaml b/skills/future-product-opportunities-from-market-inflection-points/agents/openai.yaml deleted file mode 100644 index cd0500eb..00000000 --- a/skills/future-product-opportunities-from-market-inflection-points/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Future product opportunities from market inflection points" - short_description: "Future product opportunities from market inflection points. Use when the user needs a product workflow for product..." - brand_color: "#059669" - default_prompt: "Use $future-product-opportunities-from-market-inflection-points with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/future-product-opportunities-from-market-inflection-points/productize.json b/skills/future-product-opportunities-from-market-inflection-points/productize.json deleted file mode 100644 index 659e6a26..00000000 --- a/skills/future-product-opportunities-from-market-inflection-points/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Future product opportunities from market inflection points", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "future-product-opportunities-from-market-inflection-points", - "future", - "opportunities", - "market", - "inflection", - "points" - ], - "use_when": "Future product opportunities from market inflection points. Use when the user needs a product workflow for product strategy related to future product opportunities from market inflection points. Trigger terms: strategy, foresight, market-analysis, product-discovery, trends, product-vision.", - "do_not_use_when": "Do not use Future product opportunities from market inflection points when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "future-product-opportunities-from-market-inflection-points", - "future", - "opportunities", - "market", - "inflection", - "points" - ], - "framework_fit": "Future product opportunities from market inflection points fits Strategy work in the Strategize lifecycle when the user needs Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Future product opportunities from market inflection points as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Future product opportunities from market inflection points when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $future-product-opportunities-from-market-inflection-points to turn this future context into a decision-ready Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Future product opportunities from market inflection points strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/group-decision-making-quality-review/SKILL.md b/skills/group-decision-making-quality-review/SKILL.md deleted file mode 100644 index 119cd61e..00000000 --- a/skills/group-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, - or operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group decides. ---- - - - -# Group Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `group-decision-making-quality-review` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/skills/group-decision-making-quality-review/SKILL.md.tmpl b/skills/group-decision-making-quality-review/SKILL.md.tmpl deleted file mode 100644 index de83c23d..00000000 --- a/skills/group-decision-making-quality-review/SKILL.md.tmpl +++ /dev/null @@ -1,108 +0,0 @@ ---- -name: group-decision-making-quality-review -description: >- - Review and design a group decision-making process for product, strategy, roadmap, launch, - or operating decisions. Use when the user needs to prevent groupthink, polarization, - conformity, authority bias, shared-information traps, or weak dissent before a group decides. ---- -# Group Decision Making Quality Review - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when the decision will be made or heavily influenced by a group. The output -should improve decision quality by designing the process, not by writing a generic meeting -agenda. - -Route to `meeting-outcome-planning-and-stakeholder-alignment` when the user primarily needs -a meeting plan. Use this skill when the risk is group decision failure. - -## Decision-Making Principles - -- Consensus without conflict often means relevant viewpoints are being ignored. -- Groupthink favors acceptance over correctness and weakens option testing. -- Group polarization can push a group toward a more extreme version of its initial leaning. -- Conformity, authority bias, common information effect, and sequential revelation can distort - which evidence gets heard and how strongly it is weighted. -- Private information collection, private voting, devil's advocate roles, explicit dissent, - and sequence control improve decision quality. -- Process design should fit the goal: reduce conformity when accuracy matters, or increase - commitment when alignment is the primary objective after a decision is made. - -## Workflow - -1. Define the group decision, decision owner, participants, stakes, and timeline. -2. Identify initial leaning, power dynamics, authority cues, and information asymmetry. -3. Audit groupthink, polarization, conformity, authority, common-information, and sequence risks. -4. Design the collection, discussion, dissent, voting, and commitment process. -5. Specify roles: decider, facilitator, devil's advocate, evidence owner, dissent owner, - and recorder. -6. Define decision output, confidence, unresolved dissent, and follow-up review. - -## Output Contract - -Return: - -```markdown -# Group Decision Making Quality Review - -## 1. Decision And Group Context -Decision: -Decision owner: -Participants: -Initial leaning: -Stakes: -Deadline: - -## 2. Group Decision Risks -Groupthink: -Group polarization: -Conformity: -Authority bias: -Common-information effect: -Sequential revelation / anchoring: -Hidden agendas or incentives: - -## 3. Information Collection Plan -Private inputs: -Shared evidence: -Disconfirming evidence: -Base rates: -Unknowns: - -## 4. Discussion Process -Opening frame: -Order of speakers: -Devil's advocate: -Dissent mechanism: -Conflict before consensus: -Breaks or private reflection: - -## 5. Voting And Decision Rule -Private vote: -Public commitment: -Decision rule: -Tie or escalation rule: -Decision owner override: - -## 6. Roles -Facilitator: -Decider: -Evidence owner: -Dissent owner: -Recorder: - -## 7. Final Decision Record -Decision: -Rationale: -Confidence: -Unresolved dissent: -What would change the decision: -Review date: -``` - -## Failure Modes - -- Writes a meeting agenda without addressing group decision risks. -- Treats consensus as proof of correctness. -- Omits private input, dissent, or sequence controls when conformity risk is high. -- Fails to name the decider and decision rule. diff --git a/skills/group-decision-making-quality-review/agents/openai.yaml b/skills/group-decision-making-quality-review/agents/openai.yaml deleted file mode 100644 index 4636c271..00000000 --- a/skills/group-decision-making-quality-review/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Group Decision Making Quality Review" - short_description: "Review and design a group decision-making process for product, strategy, roadmap, launch, or operating decisions...." - brand_color: "#7C2D12" - default_prompt: "Use $group-decision-making-quality-review with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/group-decision-making-quality-review/productize.json b/skills/group-decision-making-quality-review/productize.json deleted file mode 100644 index c99fdd73..00000000 --- a/skills/group-decision-making-quality-review/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Group Decision Making Quality Review", - "category": "Decision Making", - "lifecycle": "Align", - "tags": [ - "group-decision-making", - "groupthink", - "group-polarization", - "conformity-bias", - "authority-bias", - "common-information-effect", - "private-voting", - "devils-advocate", - "decision-meeting", - "group-decision-making-quality-review", - "group", - "decision", - "making", - "quality" - ], - "use_when": "Use when a product, strategy, roadmap, launch, investment, or operating decision will be made by a group and the user needs to prevent groupthink, polarization, conformity, authority bias, shared-information traps, or weak dissent.", - "do_not_use_when": "Do not use for a basic meeting agenda, stakeholder update, or personal decision review unless group decision-process quality is the central issue.", - "output_artifact": "Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record", - "routing_signals": [ - "group-decision-making", - "groupthink", - "group-polarization", - "conformity-bias", - "authority-bias", - "common-information-effect", - "private-voting", - "devil-s-advocate", - "silent-write", - "consensus-without-conflict", - "decision-meeting", - "group-decision-making-quality-review", - "group", - "decision" - ], - "framework_fit": "Best when the risk is not the decision content alone, but the social process by which a group reaches the decision.", - "failure_modes": [ - "Produces Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Group Decision Making Quality Review as generic Decision Making advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Group Decision Making Quality Review when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $group-decision-making-quality-review for our exec roadmap meeting. Everyone seems aligned too quickly and I worry sales and engineering dissent is being suppressed.", - "expected_artifact": "Group decision-making quality review with risk audit, information plan, discussion process, voting rule, roles, and decision record" - } - ] -} diff --git a/skills/grow/SKILL.md b/skills/grow/SKILL.md deleted file mode 100644 index a3911b96..00000000 --- a/skills/grow/SKILL.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -name: grow -description: >- - Productize grow playbook for stable products with activation evidence. Use when - the product has a working core and the team needs growth diagnosis, growth loops, - GTM choices, onboarding, retention, pricing, lifecycle triggers, and experiment - cadence. ---- - - - -# Productize Grow - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `grow` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition - -Use this playbook when the core product is stable enough to grow. Grow is not the -place to invent the product; use `$0-1` for new bets and `$operate` for continuous -production health. - -## Cadence - -- Trigger: stable activation, repeat usage, clear ICP, or a growth bottleneck. -- Rhythm: weekly experiment planning and readout, with metric reviews before changing - channels, onboarding, pricing, or lifecycle triggers. -- Closure: target hit, target abandoned, strategy pivot, or evidence that the product - needs a new `$0-1` loop. - -## Route Internally - -- Product-market fit and bottlenecks: `$product-market-fit-cycle`, `$aarrr-growth-diagnostics`, `$metrics-review` -- Loops and experiments: `$growth-loops`, `$plg-growth-playbook`, `$growth-project-generation-with-pioneer-migrator-settler`, `$robust-experiment-design-from-goals-and-systems` -- GTM and lifecycle: `$gtm-motions`, `$gtm-strategy`, `$onboarding-flow-optimization-from-product-data-to-user-success` -- Retention and monetization: `$churn-reduction-from-customer-data-and-exit-survey-analysis`, `$pricing-strategy`, `$monetization-strategy` -- Gates: `$product-review`, `$qa`, `$comms-review`, `$docs`, `$release` - -## Required Output - -Return: - -1. **Growth State**: ICP, activation evidence, retention signal, bottleneck, and metric caveats. -2. **Growth Thesis**: target, growth loop, channel or lifecycle trigger, and why it fits the current evidence. -3. **Experiment Cadence**: tests, owners, sample size or evidence threshold, and stop/pivot rules. -4. **Gate Calls**: product, QA, docs, release, or comms gates needed before launch. -5. **Closure Condition**: target hit, pivot, pause, or new `$0-1` bet. diff --git a/skills/grow/SKILL.md.tmpl b/skills/grow/SKILL.md.tmpl deleted file mode 100644 index b1a96a42..00000000 --- a/skills/grow/SKILL.md.tmpl +++ /dev/null @@ -1,41 +0,0 @@ ---- -name: grow -description: >- - Productize grow playbook for stable products with activation evidence. Use when - the product has a working core and the team needs growth diagnosis, growth loops, - GTM choices, onboarding, retention, pricing, lifecycle triggers, and experiment - cadence. ---- -# Productize Grow - -{{PRODUCTIZE_PREAMBLE}} - -Use this playbook when the core product is stable enough to grow. Grow is not the -place to invent the product; use `$0-1` for new bets and `$operate` for continuous -production health. - -## Cadence - -- Trigger: stable activation, repeat usage, clear ICP, or a growth bottleneck. -- Rhythm: weekly experiment planning and readout, with metric reviews before changing - channels, onboarding, pricing, or lifecycle triggers. -- Closure: target hit, target abandoned, strategy pivot, or evidence that the product - needs a new `$0-1` loop. - -## Route Internally - -- Product-market fit and bottlenecks: `$product-market-fit-cycle`, `$aarrr-growth-diagnostics`, `$metrics-review` -- Loops and experiments: `$growth-loops`, `$plg-growth-playbook`, `$growth-project-generation-with-pioneer-migrator-settler`, `$robust-experiment-design-from-goals-and-systems` -- GTM and lifecycle: `$gtm-motions`, `$gtm-strategy`, `$onboarding-flow-optimization-from-product-data-to-user-success` -- Retention and monetization: `$churn-reduction-from-customer-data-and-exit-survey-analysis`, `$pricing-strategy`, `$monetization-strategy` -- Gates: `$product-review`, `$qa`, `$comms-review`, `$docs`, `$release` - -## Required Output - -Return: - -1. **Growth State**: ICP, activation evidence, retention signal, bottleneck, and metric caveats. -2. **Growth Thesis**: target, growth loop, channel or lifecycle trigger, and why it fits the current evidence. -3. **Experiment Cadence**: tests, owners, sample size or evidence threshold, and stop/pivot rules. -4. **Gate Calls**: product, QA, docs, release, or comms gates needed before launch. -5. **Closure Condition**: target hit, pivot, pause, or new `$0-1` bet. diff --git a/skills/grow/agents/openai.yaml b/skills/grow/agents/openai.yaml deleted file mode 100644 index a5cb8c13..00000000 --- a/skills/grow/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Productize Grow" - short_description: "Productize grow playbook for stable products with activation evidence. Use when the product has a working core and..." - brand_color: "#C2410C" - default_prompt: "Use $grow with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/grow/productize.json b/skills/grow/productize.json deleted file mode 100644 index 6c6da72b..00000000 --- a/skills/grow/productize.json +++ /dev/null @@ -1,50 +0,0 @@ -{ - "title": "Productize Grow", - "category": "Growth", - "lifecycle": "Growth", - "tags": [ - "grow", - "playbook", - "entry-point", - "growth", - "activation", - "retention", - "growth-loop", - "gtm", - "experiment-cadence", - "productize", - "stable", - "evidence" - ], - "use_when": "Use Productize Grow when a product has a working core, activation evidence, and a concrete growth target or bottleneck that needs diagnosis, growth-loop design, lifecycle triggers, GTM choices, pricing, or retention experiments.", - "do_not_use_when": "Do not use Productize Grow for a raw product idea, unvalidated capability, or production health issue without a growth target. Route raw bets to 0-1 and live-product monitoring or incidents to Productize Operate.", - "output_artifact": "Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition", - "routing_signals": [ - "productize-grow", - "growth-target", - "activation-evidence", - "growth-bottleneck", - "growth-loop", - "retention", - "lifecycle-triggers", - "gtm", - "pql", - "product-led-growth", - "grow", - "productize", - "growth", - "playbook" - ], - "framework_fit": "Productize Grow fits post-activation growth work where the team needs a repeatable experiment cadence, not a new product build loop or one-time launch check. It routes to growth skills and calls product, QA, docs, release, and comms gates when experiments touch the product surface.", - "failure_modes": [ - "Starts growth experiments before the product has activation evidence, causing channel and messaging work to mask a weak core product.", - "Treats growth as generic marketing activity instead of tying each experiment to a bottleneck, loop, lifecycle trigger, metric threshold, and stop rule.", - "Skips product, QA, release, docs, or comms gates when growth changes alter onboarding, pricing, lifecycle messages, or production behavior." - ], - "examples": [ - { - "prompt": "Use $grow to diagnose our activation plateau, choose a growth loop, design the next experiment cadence, and call the right product and comms gates.", - "expected_artifact": "Growth playbook with activation evidence, bottleneck diagnosis, experiment cadence, gate calls, and closure condition" - } - ] -} diff --git a/skills/growth-loops/SKILL.md b/skills/growth-loops/SKILL.md deleted file mode 100644 index 3e589edd..00000000 --- a/skills/growth-loops/SKILL.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -name: growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- - - - -# Growth Loops - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-loops` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/growth-loops/SKILL.md.tmpl b/skills/growth-loops/SKILL.md.tmpl deleted file mode 100644 index e3640a3d..00000000 --- a/skills/growth-loops/SKILL.md.tmpl +++ /dev/null @@ -1,147 +0,0 @@ ---- -name: growth-loops -description: >- - Growth Loops. Use when designing product-led growth loops, referral loops, collaboration - loops, usage loops, or flywheels that reduce dependence on paid acquisition. ---- -# Growth Loops - -{{PRODUCTIZE_PREAMBLE}} - -Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments -- **Source method**: pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md - -## Method - -## Overview -Identify and design growth loops (flywheels) that create sustainable traction. This skill evaluates five proven growth loop mechanisms to reduce reliance on paid acquisition and build product-led growth. - -## When to Use -- Designing growth mechanisms for a product -- Building sustainable viral or referral traction -- Reducing reliance on paid acquisition -- Analyzing competitor growth strategies -- Optimizing product for product-led growth - -## The 5 Growth Loop Types - -### 1. Viral Loop -Product content created by users gets shared on external platforms, bringing new users back to the product. -- **Mechanism**: Users create content in-product -> Share on social/external platforms -> New users discover and signup -- **Example**: Figma designs shared as links, Loom videos shared in emails -- **Strength**: Exponential user acquisition if content is inherently shareable -- **Challenge**: Requires highly shareable output and strong incentive to share - -### 2. Usage Loop -Users create content or value within the product, then share it, which invites new users or drives re-engagement. -- **Mechanism**: User creates -> Shares creation -> Others consume -> Become engaged users -- **Example**: Twitter threads, Medium articles, Notion templates shared publicly -- **Strength**: Growth tied directly to product usage and network effects -- **Challenge**: Requires content creation friction to be very low - -### 3. Collaboration Loop -Users invite colleagues to co-create or collaborate within the product, expanding the user base within organizations. -- **Mechanism**: User creates -> Invites colleagues for collaboration -> Colleagues discover product value -- **Example**: Google Docs invitations, Figma team projects, Slack channels -- **Strength**: Deep organizational penetration and high retention -- **Challenge**: Works best for collaborative/team-based products - -### 4. User-Generated Loop -Users discover new content or features through other users' creations, then create and share their own content. -- **Mechanism**: User discovers content -> Creates similar content -> Shares creation -> Others discover -- **Example**: TikTok, Pinterest, YouTube trends driving creator participation -- **Strength**: Creates content flywheel and network effects -- **Challenge**: Requires critical mass of quality content to sustain - -### 5. Referral Loop -Users invite other potential users in exchange for rewards, incentives, or social recognition. -- **Mechanism**: User refers -> Referred user joins -> Referrer gets reward -> Shares more referrals -- **Example**: Dropbox referral bonus, Uber rider referrals, PayPal signup bonuses -- **Strength**: Directly incentivizes acquisition; easy to measure ROI -- **Challenge**: Requires valuable incentive without eroding unit economics - -## How It Works - -### Step 1: Define Product Value -Clarify the core value users experience: -- Primary action users take in your product -- Value created per user action -- Network effects present (if any) -- Friction points in the experience - -### Step 2: Evaluate Loop Fit -Assess which growth loops align with your product: -- Product type (collaborative, content-based, utility, etc.) -- Target user behavior and sharing habits -- Network effects already present -- Existing user base and engagement - -### Step 3: Design Loop Mechanics -Create specific loop implementation: -- Trigger that initiates sharing or invitations -- Incentive for participation (intrinsic or extrinsic) -- Ease of sharing mechanism -- Conversion rate from invite to activation -- Frequency of loop repetition per user - -### Step 4: Calculate Loop Coefficient -Estimate growth velocity: -- Invites/shares per user per cycle -- Conversion rate of invites to new users -- Net new users per cycle -- Time per cycle iteration - -### Step 5: Build the Loop -Implement the highest-leverage loop first: -- Start with the most natural loop for your product -- Optimize messaging and friction -- Measure loop metrics and conversion rates -- Compound results over time - -## Input Format -Use $ARGUMENTS to pass: -- Product description and primary user action -- Target user demographics and behavior -- Existing sharing/collaboration features -- Current growth channels and metrics -- Constraints or opportunities - -## Output -A growth loops analysis including: -- Ranked evaluation of all 5 loop types for your product -- Recommended primary growth loop with implementation plan -- Secondary loops to layer over time -- Key metrics and measurement framework -- 30-60-90 day implementation roadmap -- Potential loop coefficient and growth projections - -## Framework -Based on growth loops research by Ognjen Boskovic. Focuses on compounding user acquisition through built-in, product-native sharing and collaboration mechanisms. - -## Tips -- Start with one loop and master it before adding complexity -- Viral loops compound fastest but take time to build -- Collaboration loops create strongest retention and LTV -- Measure loop health weekly during optimization phase -- Combine loops for multiplicative effect once operating at scale - ---- - -### Further Reading - -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/growth-loops/agents/openai.yaml b/skills/growth-loops/agents/openai.yaml deleted file mode 100644 index 5a641967..00000000 --- a/skills/growth-loops/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Growth Loops" - short_description: "Growth Loops. Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or..." - brand_color: "#C2410C" - default_prompt: "Use $growth-loops with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/growth-loops/productize.json b/skills/growth-loops/productize.json deleted file mode 100644 index b332d3ba..00000000 --- a/skills/growth-loops/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Growth Loops", - "category": "Growth", - "lifecycle": "Growth", - "tags": [ - "growth-loops", - "plg", - "flywheel", - "viral", - "referral", - "collaboration", - "user-generated", - "growth", - "loops", - "marketing", - "use", - "designing", - "led" - ], - "use_when": "Use when designing product-led growth loops, referral loops, collaboration loops, usage loops, or flywheels that reduce dependence on paid acquisition.", - "do_not_use_when": "Do not use for one-off campaigns, generic funnel diagnosis, or GTM channel selection without a product mechanism that can compound.", - "output_artifact": "Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments", - "routing_signals": [ - "growth-loops", - "plg", - "flywheel", - "viral", - "referral", - "collaboration", - "user-generated", - "when", - "designing", - "product", - "growth", - "loops", - "usage", - "flywheels" - ], - "framework_fit": "Best for products where user behavior can create acquisition, activation, retention, or content/distribution effects that feed the next cycle.", - "failure_modes": [ - "Produces Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments without tying recommendations to the user's Growth stage, evidence, and decision pressure.", - "Treats Growth Loops as generic Growth advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Growth Loops when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $growth-loops to turn this plg context into a decision-ready Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments.", - "expected_artifact": "Growth loop map with loop mechanics, inputs, outputs, constraints, and experiments" - } - ], - "imported_from": "pm-skills-main/pm-go-to-market/skills/growth-loops/SKILL.md" -} diff --git a/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md b/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md deleted file mode 100644 index 951415fa..00000000 --- a/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -name: growth-project-generation-with-pioneer-migrator-settler -description: >- - Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a - product workflow for product strategy related to growth project generation with - pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, - portfolio. ---- - - - -# Growth project generation with Pioneer-Migrator-Settler framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-project-generation-with-pioneer-migrator-settler` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Growth project generation with Pioneer-Migrator-Settler framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY}} - - -GOAL -Produce a high-quality deliverable for: Growth project generation with Pioneer-Migrator-Settler framework. -Success metric: -- Produces 12 distinct growth projects categorized into Pioneer/Migrator/Settler. -- Ensures balanced portfolio logic and a brief plan to drive growth. -- Keeps ideas concrete, differentiated, and aligned to the company context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY}}`; if details are missing, state assumptions explicitly. -- Generate exactly 12 distinct growth projects: - - 3 creative, - - 3 weird, - - 3 compelling, - - 3 novel and unexpected. -- Each idea must be tagged as one of: Pioneer, Migrator, Settler. -- Keep ideas concrete and specific to the companyโ€™s context. -- Provide a brief analysis of portfolio balance and strategic impact. -- Provide a short growth plan for how to build new market space and profitable growth. - -FORMAT -Return exactly this structure: - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - - -[Brief analysis of mix and impact, with portfolio balance insights] - - - -[Brief plan for creating new market space and profitable growth] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer or more than 12 ideas are provided. -- Any idea is missing a Pioneer/Migrator/Settler category. -- Ideas are generic or not grounded in the company context. -- Analysis or growth plan is missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md.tmpl b/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md.tmpl deleted file mode 100644 index 9b8d8ec3..00000000 --- a/skills/growth-project-generation-with-pioneer-migrator-settler/SKILL.md.tmpl +++ /dev/null @@ -1,94 +0,0 @@ ---- -name: growth-project-generation-with-pioneer-migrator-settler -description: >- - Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a - product workflow for product strategy related to growth project generation with - pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, - portfolio. ---- -# Growth project generation with Pioneer-Migrator-Settler framework - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Growth project generation with Pioneer-Migrator-Settler framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{COMPANY}} - - -GOAL -Produce a high-quality deliverable for: Growth project generation with Pioneer-Migrator-Settler framework. -Success metric: -- Produces 12 distinct growth projects categorized into Pioneer/Migrator/Settler. -- Ensures balanced portfolio logic and a brief plan to drive growth. -- Keeps ideas concrete, differentiated, and aligned to the company context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{COMPANY}}`; if details are missing, state assumptions explicitly. -- Generate exactly 12 distinct growth projects: - - 3 creative, - - 3 weird, - - 3 compelling, - - 3 novel and unexpected. -- Each idea must be tagged as one of: Pioneer, Migrator, Settler. -- Keep ideas concrete and specific to the companyโ€™s context. -- Provide a brief analysis of portfolio balance and strategic impact. -- Provide a short growth plan for how to build new market space and profitable growth. - -FORMAT -Return exactly this structure: - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - -1. [Idea 1] - [Category] -2. [Idea 2] - [Category] -3. [Idea 3] - [Category] - - - - -[Brief analysis of mix and impact, with portfolio balance insights] - - - -[Brief plan for creating new market space and profitable growth] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer or more than 12 ideas are provided. -- Any idea is missing a Pioneer/Migrator/Settler category. -- Ideas are generic or not grounded in the company context. -- Analysis or growth plan is missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/growth-project-generation-with-pioneer-migrator-settler/agents/openai.yaml b/skills/growth-project-generation-with-pioneer-migrator-settler/agents/openai.yaml deleted file mode 100644 index 8fe78637..00000000 --- a/skills/growth-project-generation-with-pioneer-migrator-settler/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Growth project generation with Pioneer-Migrator-Settler framework" - short_description: "Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a product workflow for..." - brand_color: "#C2410C" - default_prompt: "Use $growth-project-generation-with-pioneer-migrator-settler with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/growth-project-generation-with-pioneer-migrator-settler/productize.json b/skills/growth-project-generation-with-pioneer-migrator-settler/productize.json deleted file mode 100644 index 1d0d96e2..00000000 --- a/skills/growth-project-generation-with-pioneer-migrator-settler/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Growth project generation with Pioneer-Migrator-Settler framework", - "category": "Growth", - "lifecycle": "Growth", - "tags": [ - "growth-project-generation-with-pioneer-migrator-settler", - "growth", - "project", - "generation", - "pioneer", - "migrator", - "settler" - ], - "use_when": "Growth project generation with Pioneer-Migrator-Settler framework. Use when the user needs a product workflow for product strategy related to growth project generation with pioneer-migrator-settler framework. Trigger terms: strategy, growth, blue-ocean, innovation, portfolio.", - "do_not_use_when": "Do not use Growth project generation with Pioneer-Migrator-Settler framework when the request is mainly generic marketing copy, product discovery, or finance valuation; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks", - "routing_signals": [ - "growth-project-generation-with-pioneer-migrator-settler", - "growth", - "project", - "generation", - "pioneer", - "migrator", - "settler" - ], - "framework_fit": "Appropriate when the user needs to turn growth possibilities into a portfolio of near-term optimizations, adjacent moves, and exploratory bets.", - "failure_modes": [ - "Produces Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks without tying recommendations to the user's Growth stage, evidence, and decision pressure.", - "Treats Growth project generation with Pioneer-Migrator-Settler framework as generic Growth advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Growth project generation with Pioneer-Migrator-Settler framework when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $growth-project-generation-with-pioneer-migrator-settler to turn this growth context into a decision-ready Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks.", - "expected_artifact": "Growth project generation with Pioneer-Migrator-Settler framework growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks" - } - ] -} diff --git a/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md b/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md deleted file mode 100644 index 74929fac..00000000 --- a/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: growth-strategy-synthesis-from-user-inputs -description: >- - Growth strategy synthesis from user inputs. Use when the user needs a product workflow for - product strategy related to growth strategy synthesis from user inputs. Trigger terms: - growth, strategy, experimentation, metrics, distribution. ---- - - - -# Growth strategy synthesis from user inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `growth-strategy-synthesis-from-user-inputs` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Growth strategy brief with bets, loops, experiments, and metrics - -Use this skill to run the Productize prompt contract for **Growth strategy synthesis from user inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUTS}} - - -GOAL -Produce a high-quality deliverable for: Growth strategy synthesis from user inputs. -Success metric: -- Produces a complete growth strategy across model, constraints, horizon, method, principle, and catalyst. -- Grounds all recommendations in the provided user inputs. -- Outputs actionable, testable recommendations and a concise summary. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUTS}}`; if critical data is missing, state assumptions explicitly. -- Address each required section: model, constraint, horizon, method, principle, catalyst, summary. -- Keep recommendations actionable and testable; avoid generic advice. -- If quantitative data is present, reference it; if not, use qualitative reasoning and label assumptions. - -FORMAT -Return exactly this structure: - - - -[Provide a detailed description of the growth model] - - - -[Identify and explain the main growth constraints] - - - -[Analyze the growth horizon and potential limitations] - - - -[Propose specific methods to address constraints and extend the growth horizon] - - - -[Develop a guiding principle for aligning the organization] - - - -[Identify and explain any growth catalysts] - - - -[Provide a brief summary of the overall growth strategy] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Recommendations are not tied to the provided inputs. -- Growth method lacks actionable steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md.tmpl b/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md.tmpl deleted file mode 100644 index 2d5f49a9..00000000 --- a/skills/growth-strategy-synthesis-from-user-inputs/SKILL.md.tmpl +++ /dev/null @@ -1,81 +0,0 @@ ---- -name: growth-strategy-synthesis-from-user-inputs -description: >- - Growth strategy synthesis from user inputs. Use when the user needs a product workflow for - product strategy related to growth strategy synthesis from user inputs. Trigger terms: - growth, strategy, experimentation, metrics, distribution. ---- -# Growth strategy synthesis from user inputs - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Growth strategy synthesis from user inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_INPUTS}} - - -GOAL -Produce a high-quality deliverable for: Growth strategy synthesis from user inputs. -Success metric: -- Produces a complete growth strategy across model, constraints, horizon, method, principle, and catalyst. -- Grounds all recommendations in the provided user inputs. -- Outputs actionable, testable recommendations and a concise summary. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{USER_INPUTS}}`; if critical data is missing, state assumptions explicitly. -- Address each required section: model, constraint, horizon, method, principle, catalyst, summary. -- Keep recommendations actionable and testable; avoid generic advice. -- If quantitative data is present, reference it; if not, use qualitative reasoning and label assumptions. - -FORMAT -Return exactly this structure: - - - -[Provide a detailed description of the growth model] - - - -[Identify and explain the main growth constraints] - - - -[Analyze the growth horizon and potential limitations] - - - -[Propose specific methods to address constraints and extend the growth horizon] - - - -[Develop a guiding principle for aligning the organization] - - - -[Identify and explain any growth catalysts] - - - -[Provide a brief summary of the overall growth strategy] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Recommendations are not tied to the provided inputs. -- Growth method lacks actionable steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/growth-strategy-synthesis-from-user-inputs/agents/openai.yaml b/skills/growth-strategy-synthesis-from-user-inputs/agents/openai.yaml deleted file mode 100644 index 887ef6a5..00000000 --- a/skills/growth-strategy-synthesis-from-user-inputs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Growth strategy synthesis from user inputs" - short_description: "Growth strategy synthesis from user inputs. Use when the user needs a product workflow for product strategy related..." - brand_color: "#C2410C" - default_prompt: "Use $growth-strategy-synthesis-from-user-inputs with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/growth-strategy-synthesis-from-user-inputs/productize.json b/skills/growth-strategy-synthesis-from-user-inputs/productize.json deleted file mode 100644 index 92a6120e..00000000 --- a/skills/growth-strategy-synthesis-from-user-inputs/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Growth strategy synthesis from user inputs", - "category": "Growth", - "lifecycle": "Growth", - "tags": [ - "growth-strategy-synthesis-from-user-inputs", - "growth", - "synthesis", - "inputs", - "use" - ], - "use_when": "Growth strategy synthesis from user inputs. Use when the user needs a product workflow for product strategy related to growth strategy synthesis from user inputs. Trigger terms: growth, strategy, experimentation, metrics, distribution.", - "do_not_use_when": "Do not use Growth strategy synthesis from user inputs when the request is mainly generic marketing copy, product discovery, or finance valuation; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Growth strategy brief with bets, loops, experiments, and metrics", - "routing_signals": [ - "growth-strategy-synthesis-from-user-inputs", - "growth", - "synthesis", - "inputs", - "use" - ], - "framework_fit": "Appropriate when the user has inputs about market, product, audience, traction, channels, or constraints and needs a coherent growth plan rather than a broad company strategy.", - "failure_modes": [ - "Produces Growth strategy brief with bets, loops, experiments, and metrics without tying recommendations to the user's Growth stage, evidence, and decision pressure.", - "Treats Growth strategy synthesis from user inputs as generic Growth advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Growth strategy synthesis from user inputs when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $growth-strategy-synthesis-from-user-inputs to turn this growth context into a decision-ready Growth strategy brief with bets, loops, experiments, and metrics.", - "expected_artifact": "Growth strategy brief with bets, loops, experiments, and metrics" - } - ] -} diff --git a/skills/gtm-motions/SKILL.md b/skills/gtm-motions/SKILL.md deleted file mode 100644 index 47c50364..00000000 --- a/skills/gtm-motions/SKILL.md +++ /dev/null @@ -1,236 +0,0 @@ ---- -name: gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, - community, partner, ABM, or hybrid go-to-market motions. ---- - - - -# GTM Motions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-motions` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/gtm-motions/SKILL.md.tmpl b/skills/gtm-motions/SKILL.md.tmpl deleted file mode 100644 index 10231e31..00000000 --- a/skills/gtm-motions/SKILL.md.tmpl +++ /dev/null @@ -1,177 +0,0 @@ ---- -name: gtm-motions -description: >- - GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, - community, partner, ABM, or hybrid go-to-market motions. ---- -# GTM Motions - -{{PRODUCTIZE_PREAMBLE}} - -Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: none -- **Primary artifact**: GTM motion selection brief with channel fit, operating requirements, and experiment plan -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md - -## Method - -## Overview -Identify and evaluate the best go-to-market motions for your product. This skill analyzes seven proven GTM approaches with specific tools and tactics to help you build a balanced acquisition strategy. - -## When to Use -- Selecting marketing channels for your product -- Choosing between inbound vs outbound strategy -- Building your GTM toolkit and tech stack -- Evaluating PLG vs traditional sales motion -- Planning cross-channel marketing campaigns - -## The 7 GTM Motions - -### 1. Inbound Marketing -Attract customers through valuable content and thought leadership. -- **Tools**: LinkedIn, SEMRush, Grammarly, HubSpot, Airtable -- **Tactics**: Blog content, webinars, whitepapers, SEO, email nurture sequences -- **Best For**: B2B SaaS, technical products, long sales cycles -- **Strength**: Builds brand authority and attracts high-intent prospects -- **Challenge**: Requires consistent content creation; slower to show results - -### 2. Outbound Sales -Proactively reach target prospects through direct engagement. -- **Tools**: LinkedIn Sales Navigator, ZoomInfo, Lemlist, Apollo, Hunter -- **Tactics**: Cold email campaigns, LinkedIn outreach, phone prospecting, personalized demos -- **Best For**: Enterprise sales, high-value contracts, niche markets -- **Strength**: Predictable pipeline generation; control over target selection -- **Challenge**: Low response rates; resource-intensive; requires skilled sales team - -### 3. Paid Digital Advertising -Reach target audiences through paid channels with precision targeting. -- **Tools**: Google Ads, Meta Ads, LinkedIn Ads, Newswire, Retargeting platforms -- **Tactics**: Search ads, display advertising, social ads, video advertising, retargeting -- **Best For**: Products with clear target demographics, competitive keywords -- **Strength**: Fast results; scalable; measurable ROI; precise targeting -- **Challenge**: Can be expensive; requires continuous optimization; competitive - -### 4. Community Marketing -Build engaged communities where customers help each other and spread the word. -- **Tools**: Slack, Reddit, Discord, Circle, Mighty Networks, WhatsApp -- **Tactics**: Community forums, user groups, events, mentorship, ambassador programs -- **Best For**: Developer products, communities of practice, loyal user bases -- **Strength**: Builds loyalty; organic word-of-mouth; valuable feedback; low CAC -- **Challenge**: Requires active moderation; time to build critical mass - -### 5. Partner Marketing -Leverage partner networks to co-market and reach new audiences. -- **Tools**: Miro, AWS Startups, Oracle Partners, Stripe, Shopify App Store -- **Tactics**: Partner integrations, co-marketing agreements, channel partnerships, resellers -- **Best For**: Complementary products, platform ecosystems, expanding market reach -- **Strength**: Access to established customer bases; shared costs; credibility -- **Challenge**: Partner alignment; revenue sharing; dependency on partners - -### 6. Account-Based Marketing (ABM) -Treat high-value accounts as individual markets with personalized campaigns. -- **Tools**: Pipedrive, Hunter, Clay, 6sense, Terminus, Demandbase -- **Tactics**: Personalized messaging, account-targeted content, coordinated sales/marketing -- **Best For**: Enterprise deals, limited target accounts, high deal values -- **Strength**: Higher conversion rates; larger deal sizes; strong sales-marketing alignment -- **Challenge**: Requires detailed account research; resource intensive; not scalable to SMB - -### 7. Product-Led Growth (PLG) -Drive adoption through the product experience itself with minimal sales friction. -- **Tools**: Hotjar, Amplitude, Sentry, PostHog, Intercom, Appcues -- **Tactics**: Free trials, freemium models, in-app onboarding, self-serve demos, product analytics -- **Best For**: Self-service products, SMB market, low ACV, viral potential -- **Strength**: Low CAC; aligns product and growth; strong PMF signals; scalable -- **Challenge**: Requires excellent product experience; lower price points; longer ROI - -## How It Works - -### Step 1: Understand Your Product -Define product characteristics: -- Price point and ACV (contract value) -- Sales cycle length -- Buyer type and decision-making process -- Product complexity and learning curve -- Target market size and concentration - -### Step 2: Evaluate Market Conditions -Assess your market dynamics: -- Competitive intensity of your keywords/channels -- Target audience location and accessibility -- Budget availability for paid channels -- Your team size and capabilities -- Timeline to revenue generation - -### Step 3: Score Each Motion -Rate fit for your product (1-10 scale): -- Inbound: Content creation capability, brand building timeline -- Outbound: Prospect list availability, sales team capacity -- Paid: Budget flexibility, target audience clarity, conversion potential -- Community: Existing communities, product network effects -- Partners: Complementary products, channel availability -- ABM: Deal size and account concentration -- PLG: Product trial-ability, pricing flexibility - -### Step 4: Design Motion Stack -Select and prioritize 2-4 motions to execute: -- Primary motion (highest potential for your business) -- Secondary motions (complementary acquisition channels) -- Motion sequencing (which to start first) -- Resource allocation across channels - -### Step 5: Build Execution Plan -Create 90-day implementation roadmap: -- Quick wins and early validation -- Team and tool requirements -- Success metrics for each motion -- Optimization and scaling strategy -- Budget and resource allocation - -## Input Format -Use $ARGUMENTS to pass: -- Product description and positioning -- Target customer profile and market -- Price point and sales cycle -- Team size and capabilities -- Budget and timeline constraints -- Existing channels or data - -## Output -A comprehensive GTM motions analysis including: -- Scoring of all 7 motions for your product -- Recommended motion stack (primary and secondary) -- Tool recommendations for each motion -- 90-day execution plan with milestones -- Resource and budget requirements -- Success metrics and measurement framework -- Competitive differentiation through motion choice - -## Framework -Based on Product Compass GTM motion analysis. Provides a systematic approach to balancing customer acquisition across multiple channels. - -## Tips -- Most successful products use 2-4 complementary motions -- Start with your strongest motion; add complexity gradually -- Paid channels fund growth while organic channels build long-term value -- Revisit motion mix quarterly as company scales -- Combine inbound (brand) with outbound (sales) for B2B strength -- Use PLG to reduce CAC; use paid to accelerate proven channels - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product Management vs. Product Marketing vs. Product Growth 101](https://www.productcompass.pm/p/product-management-vs-product-marketing) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/gtm-motions/agents/openai.yaml b/skills/gtm-motions/agents/openai.yaml deleted file mode 100644 index 174ed8f3..00000000 --- a/skills/gtm-motions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "GTM Motions" - short_description: "GTM Motions. Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid..." - brand_color: "#C2410C" - default_prompt: "Use $gtm-motions with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/gtm-motions/productize.json b/skills/gtm-motions/productize.json deleted file mode 100644 index c0d60e30..00000000 --- a/skills/gtm-motions/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "GTM Motions", - "category": "Growth", - "lifecycle": "Growth", - "tags": [ - "gtm-motions", - "gtm", - "plg", - "sales-led", - "inbound", - "outbound", - "abm", - "partners", - "community", - "motions", - "marketing", - "use", - "selecting", - "between" - ], - "use_when": "Use when selecting between PLG, sales-led, inbound, outbound, paid, community, partner, ABM, or hybrid go-to-market motions.", - "do_not_use_when": "Do not use when the user only needs launch copy, a broad market strategy, or a growth-loop design rather than motion selection.", - "output_artifact": "GTM motion selection brief with channel fit, operating requirements, and experiment plan", - "routing_signals": [ - "gtm-motions", - "gtm", - "plg", - "sales-led", - "inbound", - "outbound", - "abm", - "partners", - "community", - "when", - "selecting", - "between", - "sales", - "paid" - ], - "framework_fit": "Best when the product has a defined audience and the team needs to choose acquisition and sales motions that match ACV, buyer, urgency, and product complexity.", - "failure_modes": [ - "Produces GTM motion selection brief with channel fit, operating requirements, and experiment plan without tying recommendations to the user's Growth stage, evidence, and decision pressure.", - "Treats GTM Motions as generic Growth advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from GTM Motions when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $gtm-motions to turn this gtm context into a decision-ready GTM motion selection brief with channel fit, operating requirements, and experiment plan.", - "expected_artifact": "GTM motion selection brief with channel fit, operating requirements, and experiment plan" - } - ], - "imported_from": "pm-skills-main/pm-go-to-market/skills/gtm-motions/SKILL.md" -} diff --git a/skills/gtm-strategy/SKILL.md b/skills/gtm-strategy/SKILL.md deleted file mode 100644 index eed10337..00000000 --- a/skills/gtm-strategy/SKILL.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- - - - -# GTM Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `gtm-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/gtm-strategy/SKILL.md.tmpl b/skills/gtm-strategy/SKILL.md.tmpl deleted file mode 100644 index f1c5dca4..00000000 --- a/skills/gtm-strategy/SKILL.md.tmpl +++ /dev/null @@ -1,116 +0,0 @@ ---- -name: gtm-strategy -description: >- - GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market - entry, launch, or repositioning effort. ---- -# GTM Strategy - -{{PRODUCTIZE_PREAMBLE}} - -Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort. - -## Productize Contract - -- **Primary lifecycle**: Growth -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: Go-to-market plan with audience, positioning, channels, metrics, and launch timeline -- **Source method**: pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md - -## Method - -## Overview -Create a comprehensive go-to-market strategy for a product launch. This skill covers marketing channels, messaging development, success metrics definition, and launch planning. - -## When to Use -- Planning a product launch -- Creating a GTM plan from scratch -- Defining a launch strategy for a new market -- Developing product-to-market fit strategy -- Preparing a product go-live roadmap - -## How It Works - -### Step 1: Gather Research Data -The system will help you load and analyze early research about your product and target market. Provide: -- Product description and key features -- Target market segment details -- Market research or validation data -- Competitive landscape information -- Any available customer interviews or survey data - -### Step 2: Define Marketing Channels -Evaluate which channels best reach your target audience: -- Digital marketing channels (paid search, social media, display) -- Content and inbound channels (blog, SEO, thought leadership) -- Sales and outbound channels (direct outreach, partnerships) -- Community and grassroots channels -- Product-led and viral channels - -### Step 3: Develop Messaging -Create audience-specific messaging that resonates: -- Core value proposition for target segment -- Key differentiators and competitive advantages -- Pain point validation and solution mapping -- Proof points and social proof strategies -- Channel-specific messaging variations - -### Step 4: Define Success Metrics -Establish measurable KPIs to track launch success: -- Awareness metrics (impressions, reach, brand recall) -- Engagement metrics (CTR, cost per engagement, time on site) -- Conversion metrics (signups, demos requested, trials started) -- Revenue metrics (MRR, customer acquisition cost, lifetime value) -- Market metrics (market share, segment penetration) - -### Step 5: Create Launch Plan -Build a phased launch timeline: -- Pre-launch preparation (messaging, channels, timeline) -- Launch day activities and announcements -- Post-launch momentum (content, partnerships, communities) -- Measurement and optimization cadence -- Success criteria and go/no-go decision points - -## Input Format -Use $ARGUMENTS to pass: -- Product name and description -- Target market segment -- Research data or file path -- Launch timeline and constraints -- Budget or resource limitations - -## Output -A structured GTM strategy document including: -- Recommended marketing channels with justification -- Channel-specific messaging and positioning -- Launch timeline with key milestones -- KPI targets and measurement framework -- Risk mitigation strategies -- 90-day execution roadmap - -## Framework -This skill applies Product Compass GTM strategy methodology, focusing on market selection, channel fit, and message-market fit for sustainable product growth. - -## Tips -- Start with your most confident customer segment -- Validate assumptions through customer interviews before full launch -- Focus on a few channels excellently rather than many channels poorly -- Establish baseline metrics before launch to measure impact -- Plan for feedback loops and optimization - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [OpenAI's Product Leader Shares 3-Layer Distribution Framework To Win Mind & Market Share in the AI World](https://www.productcompass.pm/p/distribution-framework-ai-products) -- [Product-Led Growth 101, Part 1/2](https://www.productcompass.pm/p/product-led-growth-101-12) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [How to Achieve Product-Market Fit? Part I: Market and Value Proposition](https://www.productcompass.pm/p/how-to-achieve-the-product-market) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/gtm-strategy/agents/openai.yaml b/skills/gtm-strategy/agents/openai.yaml deleted file mode 100644 index ddf57830..00000000 --- a/skills/gtm-strategy/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "GTM Strategy" - short_description: "GTM Strategy. Use when creating a full go-to-market plan for a product, feature, market entry, launch, or..." - brand_color: "#C2410C" - default_prompt: "Use $gtm-strategy with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/gtm-strategy/productize.json b/skills/gtm-strategy/productize.json deleted file mode 100644 index 8c7a9af0..00000000 --- a/skills/gtm-strategy/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "GTM Strategy", - "category": "Growth", - "lifecycle": "Growth", - "tags": [ - "gtm-strategy", - "gtm", - "launch", - "channels", - "messaging", - "success-metrics", - "timeline", - "launch-and-learn", - "marketing", - "use", - "creating", - "full", - "market", - "plan" - ], - "use_when": "Use when creating a full go-to-market plan for a product, feature, market entry, launch, or repositioning effort.", - "do_not_use_when": "Do not use for narrow channel selection, pure launch comms, or a strategy memo without GTM execution requirements.", - "output_artifact": "Go-to-market plan with audience, positioning, channels, metrics, and launch timeline", - "routing_signals": [ - "gtm-strategy", - "gtm", - "launch", - "channels", - "messaging", - "success-metrics", - "timeline", - "when", - "creating", - "full", - "market", - "plan", - "product", - "feature" - ], - "framework_fit": "Best when the team needs a launchable GTM plan connecting target audience, message, channels, motions, timeline, owners, and metrics.", - "failure_modes": [ - "Produces Go-to-market plan with audience, positioning, channels, metrics, and launch timeline without tying recommendations to the user's Growth stage, evidence, and decision pressure.", - "Treats GTM Strategy as generic Growth advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from GTM Strategy when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $gtm-strategy to turn this gtm context into a decision-ready Go-to-market plan with audience, positioning, channels, metrics, and launch timeline.", - "expected_artifact": "Go-to-market plan with audience, positioning, channels, metrics, and launch timeline" - } - ], - "imported_from": "pm-skills-main/pm-go-to-market/skills/gtm-strategy/SKILL.md" -} diff --git a/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md b/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md deleted file mode 100644 index af1e4586..00000000 --- a/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- - - - -# Ideal Customer Profile (ICP) representative for X product - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideal-customer-profile-icp-representative-for-x-product` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md.tmpl b/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md.tmpl deleted file mode 100644 index 2ab393ae..00000000 --- a/skills/ideal-customer-profile-icp-representative-for-x-product/SKILL.md.tmpl +++ /dev/null @@ -1,91 +0,0 @@ ---- -name: ideal-customer-profile-icp-representative-for-x-product -description: >- - Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product - workflow for user research related to ideal customer profile (icp) representative for x - product. Trigger terms: user-research, icp, personas. ---- -# Ideal Customer Profile (ICP) representative for X product - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Ideal Customer Profile (ICP) representative for X product**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_NAME}} -- {{ICP_PROFILE}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: Ideal Customer Profile (ICP) representative for X product. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Answer `{{PM_QUESTION}}` as the ICP voice for `{{PRODUCT_NAME}}`, using `{{ICP_PROFILE}}` as the source of truth. -- Ground responses in specific, first-person, concrete experiences and observable behavior. -- Prefer recent, timestamped examples and workflow context (what happened, where, with which tools, and outcome). -- For hypothetical/aggregate questions, redirect to concrete experienced examples; do not generalize to all users. -- If experience is missing, explicitly state "I don't know from direct experience" and explain the limit. -- Do not invent usage events, feature exposure, or claims not supported by provided context. -- Focus on actionable product feedback: what worked, what failed, impact, and why it matters. - -FORMAT -Return exactly this structure: - -ICP Response - -Question -[Restate `{{PM_QUESTION}}` in one line] - -Recent Real Experiences -- [Specific instance with timing/context] -- [Specific instance with timing/context] - -What Worked -- [Concrete behavior/outcome and why] - -What Didn't Work -- [Concrete friction/failure and impact] - -Workflow Context -- [Step-by-step summary of how task was done in practice] - -Redirect (if question is hypothetical/aggregate) -- [Short first-person redirection to real experience] - -Confidence & Limits -- Confidence: [High/Medium/Low] -- Limits: [What is unknown or not directly experienced] - -Actionable Takeaway for PM -- [Specific implication for product decision] - -FAILURE -- Any required section is missing or materially incomplete. -- Response is hypothetical, generic, or not rooted in provided ICP context. -- Claims are made without concrete experience examples or stated limits. -- Response speaks for all users instead of first-person ICP perspective. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `ideal customer profile`, `icp`, `pmf survey`, `best customers`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/ideal-customer-profile-icp-representative-for-x-product/agents/openai.yaml b/skills/ideal-customer-profile-icp-representative-for-x-product/agents/openai.yaml deleted file mode 100644 index 381106ba..00000000 --- a/skills/ideal-customer-profile-icp-representative-for-x-product/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Ideal Customer Profile (ICP) representative for X product" - short_description: "Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product workflow for user..." - brand_color: "#0D9488" - default_prompt: "Use $ideal-customer-profile-icp-representative-for-x-product with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/ideal-customer-profile-icp-representative-for-x-product/productize.json b/skills/ideal-customer-profile-icp-representative-for-x-product/productize.json deleted file mode 100644 index ce5d03d8..00000000 --- a/skills/ideal-customer-profile-icp-representative-for-x-product/productize.json +++ /dev/null @@ -1,45 +0,0 @@ -{ - "title": "Ideal Customer Profile (ICP) representative for X product", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "ideal-customer-profile-icp-representative-for-x-product", - "ideal", - "customer", - "profile", - "icp", - "representative", - "ideal-customer-profile", - "pmf-survey", - "best-customers" - ], - "use_when": "Ideal Customer Profile (ICP) representative for X product. Use when the user needs a product workflow for user research related to ideal customer profile (icp) representative for x product. Trigger terms: user-research, icp, personas.", - "do_not_use_when": "Do not use Ideal Customer Profile (ICP) representative for X product when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "ideal-customer-profile-icp-representative-for-x-product", - "ideal", - "customer", - "profile", - "icp", - "representative", - "ideal-customer-profile", - "pmf-survey", - "best-customers" - ], - "framework_fit": "Ideal Customer Profile (ICP) representative for X product fits Discovery work in the Discover lifecycle when the user needs Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Ideal Customer Profile (ICP) representative for X product as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Ideal Customer Profile (ICP) representative for X product when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $ideal-customer-profile-icp-representative-for-x-product to turn this ideal context into a decision-ready Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Ideal Customer Profile (ICP) representative for X product research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ], - "references": [ - "references/pm-skills-main-merge.md" - ] -} diff --git a/skills/ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md b/skills/ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md deleted file mode 100644 index 3be9171c..00000000 --- a/skills/ideal-customer-profile-icp-representative-for-x-product/references/pm-skills-main-merge.md +++ /dev/null @@ -1,171 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make ICP outputs sharper on demographics, behaviors, JTBD, PMF evidence, and best-customer patterns. - -## Routing Signals - -- ideal customer profile -- icp -- pmf survey -- best customers - -## pm-go-to-market/skills/ideal-customer-profile/SKILL.md - -## Overview -Identify your Ideal Customer Profile (ICP) from research and survey data. This skill synthesizes customer research to define the customer most likely to find value, retain, and expand with your product. - -## When to Use -- Defining ICP from product-market fit survey data -- Targeting high-value customer segments -- Analyzing customer success and expansion patterns -- Prioritizing sales and marketing efforts -- Evaluating new customer opportunities for fit -- Refining target market definition - -## ICP Framework Components - -### Demographics -Who are they from a firmographic and personal perspective? -- Company size (employees, revenue) -- Industry or vertical -- Geographic location -- Job title and department -- Years of experience in role -- Education and background -- Organizational structure and reporting - -### Behaviors -How do they work and make decisions? -- How they discover and evaluate solutions -- Buying process and decision-making timeline -- Technical literacy and product adoption speed -- Collaboration style (solo decision vs committee) -- Change management and adoption style -- Tool switching frequency -- Community involvement and peer influence - -### Jobs to Be Done (JTBD) -What are they trying to accomplish? -- Primary job/goal they're trying to achieve -- Secondary jobs that support the primary job -- Emotional jobs (how they want to feel) -- Social jobs (status and perception) -- Jobs they avoid or want to eliminate -- Frequency and importance of each job -- Success metrics for completing job - -### Needs and Pain Points -What problems does your product solve? -- Specific pain points they experience -- Current workarounds and limitations -- Impact on productivity or outcomes -- Cost or time burden of the problem -- Emotional frustration levels -- Barriers to solving the problem -- Available budget to solve -- Competing priorities - -## How It Works - -### Step 1: Gather Customer Data -Collect research about actual and potential customers: -- Product-market fit survey responses -- Customer interview transcripts -- Trial or freemium user behavior data -- Customer feedback and support tickets -- Churn analysis and customer lifecycle data -- Win/loss analysis from sales -- Competitor customer analysis - -### Step 2: Segment by Value -Identify customer cohorts and their value: -- Highest LTV (lifetime value) customers -- Fastest time-to-value customers -- Lowest churn rate customers -- Highest expansion/upsell customers -- Most enthusiastic/engaged customers -- Best reference/case study potential -- Most aligned with product vision - -### Step 3: Profile Demographics -Extract firmographic patterns: -- Common company sizes (employee count, revenue) -- Industry verticals and sub-verticals -- Geographic concentrations -- Typical department and reporting structure -- Budget holders and budget available -- Company stage (startup, growth, enterprise) -- Company culture indicators - -### Step 4: Identify Behaviors -Map decision-making and adoption patterns: -- How they discovered your product (channel) -- Evaluation process and timeline -- Key stakeholders in decision -- Obstacles during sales process -- Product adoption speed and breadth -- Team involvement in onboarding -- Frequency of feature usage -- Support and service needs - -### Step 5: Define JTBD -Articulate what they're trying to accomplish: -- Primary job/goal (functional job) -- Emotional dimensions (how they want to feel) -- Social dimensions (team and stakeholder impact) -- Success metrics (how they measure success) -- Context and constraints (when, where, with whom) -- Competing jobs and priorities -- Importance ranking of various jobs - -### Step 6: Document Pain Points and Needs -Synthesize specific problem areas: -- Before state (current situation and frustrations) -- Desired after state (ideal future state) -- Gap size and impact quantification -- Emotional dimensions of the problem -- Resource constraints preventing solutions -- Skepticism or hesitations -- Success criteria for solution - -## Input Format -Use $ARGUMENTS to pass: -- Research data (surveys, interviews, transcripts) -- Customer success/metrics data -- Product usage analytics -- Sales activity and win/loss data -- Existing customer database -- Competitive intelligence - -## Output -A comprehensive ICP definition including: -- Firmographic profile (company size, industry, location) -- Behavioral profile (buying patterns, adoption style) -- Complete JTBD mapping (functional, emotional, social jobs) -- Top 5-7 pain points and specific needs -- Quantified impact metrics (cost of problem, value of solution) -- Decision-making process and key stakeholders -- Typical customer journey and timeline -- Go-to-market implications and messaging -- Disqualification criteria (who is NOT a good fit) -- High-value segment within ICP (ideal-of-the-ideal) - -## Framework -Based on Jobs to Be Done theory by Clayton Christensen and customer profiling methodology. Combines behavioral data with motivational insights to define actionable customer profiles. - -## Tips -- Use quantitative and qualitative data together -- Interview 10+ high-value customers for pattern identification -- Look for non-obvious demographic patterns (outliers can be high-value) -- Define both ideal ICP and acceptable secondary segments -- Revisit ICP quarterly as you gather more customer data -- Use ICP to evaluate all new sales opportunities -- Share ICP across entire organization (marketing, sales, product) -- Remember: ICP should drive focus, not exclude all others - ---- - -### Further Reading - -- [5 GTM Principles You Should Know as a PM](https://www.productcompass.pm/p/5-gtm-principles-with-frameworks-templates) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) diff --git a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md b/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md deleted file mode 100644 index d08f9913..00000000 --- a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: ideas-for-affordances-and-signifiers-based-on-a-design-problem -description: >- - Ideas for affordances and signifiers based on a design problem. Use when the user needs a - product workflow for design & prototyping related to ideas for affordances and signifiers - based on a design problem. Trigger terms: ux, interaction-design, affordances, usability. ---- - - - -# Ideas for affordances and signifiers based on a design problem - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ideas-for-affordances-and-signifiers-based-on-a-design-problem` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Ideas for affordances and signifiers based on a design problem**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_CHALLENGE}} - - -GOAL -Produce a high-quality deliverable for: Ideas for affordances and signifiers based on a design problem. -Success metric: -- Identifies key user interactions in the design challenge before proposing ideas. -- Produces at least 5 concrete ideas each for affordances, perceived affordances, and signifiers. -- Each idea includes a brief explanation tied to the challenge and UX impact. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DESIGN_CHALLENGE}}`; if context is incomplete, state assumptions explicitly. -- Start with a brief interaction analysis identifying main user functions/tasks. -- Generate at least 5 ideas in each category: affordances, perceived affordances, signifiers. -- For every idea, include a short explanation linking: - - the specific challenge friction/opportunity, - - how the idea guides user action or perception, - - expected UX improvement. -- Keep ideas practical, non-generic, and directly relevant to the described product context. - -FORMAT -Return exactly this structure: - - - -[Main user interactions/functions required by the challenge] - - - -1. [Affordance idea] - [Brief explanation] -2. [Affordance idea] - [Brief explanation] -3. [Affordance idea] - [Brief explanation] -4. [Affordance idea] - [Brief explanation] -5. [Affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Perceived affordance idea] - [Brief explanation] -2. [Perceived affordance idea] - [Brief explanation] -3. [Perceived affordance idea] - [Brief explanation] -4. [Perceived affordance idea] - [Brief explanation] -5. [Perceived affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Signifier idea] - [Brief explanation] -2. [Signifier idea] - [Brief explanation] -3. [Signifier idea] - [Brief explanation] -4. [Signifier idea] - [Brief explanation] -5. [Signifier idea] - [Brief explanation] -[Optional additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 5 ideas in any required category. -- Explanations are missing for one or more ideas. -- No interaction analysis is provided before idea lists. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md.tmpl b/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md.tmpl deleted file mode 100644 index 1be1dfdf..00000000 --- a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/SKILL.md.tmpl +++ /dev/null @@ -1,89 +0,0 @@ ---- -name: ideas-for-affordances-and-signifiers-based-on-a-design-problem -description: >- - Ideas for affordances and signifiers based on a design problem. Use when the user needs a - product workflow for design & prototyping related to ideas for affordances and signifiers - based on a design problem. Trigger terms: ux, interaction-design, affordances, usability. ---- -# Ideas for affordances and signifiers based on a design problem - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Ideas for affordances and signifiers based on a design problem**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_CHALLENGE}} - - -GOAL -Produce a high-quality deliverable for: Ideas for affordances and signifiers based on a design problem. -Success metric: -- Identifies key user interactions in the design challenge before proposing ideas. -- Produces at least 5 concrete ideas each for affordances, perceived affordances, and signifiers. -- Each idea includes a brief explanation tied to the challenge and UX impact. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DESIGN_CHALLENGE}}`; if context is incomplete, state assumptions explicitly. -- Start with a brief interaction analysis identifying main user functions/tasks. -- Generate at least 5 ideas in each category: affordances, perceived affordances, signifiers. -- For every idea, include a short explanation linking: - - the specific challenge friction/opportunity, - - how the idea guides user action or perception, - - expected UX improvement. -- Keep ideas practical, non-generic, and directly relevant to the described product context. - -FORMAT -Return exactly this structure: - - - -[Main user interactions/functions required by the challenge] - - - -1. [Affordance idea] - [Brief explanation] -2. [Affordance idea] - [Brief explanation] -3. [Affordance idea] - [Brief explanation] -4. [Affordance idea] - [Brief explanation] -5. [Affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Perceived affordance idea] - [Brief explanation] -2. [Perceived affordance idea] - [Brief explanation] -3. [Perceived affordance idea] - [Brief explanation] -4. [Perceived affordance idea] - [Brief explanation] -5. [Perceived affordance idea] - [Brief explanation] -[Optional additional ideas] - - - -1. [Signifier idea] - [Brief explanation] -2. [Signifier idea] - [Brief explanation] -3. [Signifier idea] - [Brief explanation] -4. [Signifier idea] - [Brief explanation] -5. [Signifier idea] - [Brief explanation] -[Optional additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 5 ideas in any required category. -- Explanations are missing for one or more ideas. -- No interaction analysis is provided before idea lists. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/agents/openai.yaml b/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/agents/openai.yaml deleted file mode 100644 index 1e9e0246..00000000 --- a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Ideas for affordances and signifiers based on a design problem" - short_description: "Ideas for affordances and signifiers based on a design problem. Use when the user needs a product workflow for..." - brand_color: "#DB2777" - default_prompt: "Use $ideas-for-affordances-and-signifiers-based-on-a-design-problem with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/productize.json b/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/productize.json deleted file mode 100644 index 72035401..00000000 --- a/skills/ideas-for-affordances-and-signifiers-based-on-a-design-problem/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Ideas for affordances and signifiers based on a design problem", - "category": "Design", - "lifecycle": "Design", - "tags": [ - "ideas-for-affordances-and-signifiers-based-on-a-design-problem", - "ideas", - "affordances", - "signifiers", - "design", - "problem" - ], - "use_when": "Ideas for affordances and signifiers based on a design problem. Use when the user needs a product workflow for design & prototyping related to ideas for affordances and signifiers based on a design problem. Trigger terms: ux, interaction-design, affordances, usability.", - "do_not_use_when": "Do not use Ideas for affordances and signifiers based on a design problem when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "ideas-for-affordances-and-signifiers-based-on-a-design-problem", - "ideas", - "affordances", - "signifiers", - "design", - "problem" - ], - "framework_fit": "Ideas for affordances and signifiers based on a design problem fits Design work in the Design lifecycle when the user needs Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Ideas for affordances and signifiers based on a design problem as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Ideas for affordances and signifiers based on a design problem when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $ideas-for-affordances-and-signifiers-based-on-a-design-problem to turn this ideas context into a decision-ready Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Ideas for affordances and signifiers based on a design problem UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/implementation-notes/SKILL.md b/skills/implementation-notes/SKILL.md deleted file mode 100644 index e419ddcd..00000000 --- a/skills/implementation-notes/SKILL.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: implementation-notes -description: >- - Running implementation-notes protocol for spec-driven builds. Use when the user - asks the agent to maintain implementation-notes.md or implementation-notes.html - with decisions, deviations, tradeoffs, open questions, and verification while - implementing a feature, fix, or product slice. ---- - - - -# Implementation Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `implementation-notes` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence - -Use this skill when implementation work needs a durable notes artifact that keeps -the user in the loop without stopping progress for every ambiguity. - -This is not a verbose work log. It records the meaningful places where the spec -was interpreted, narrowed, changed, or found incomplete. - -## Activation - -Activate alongside `$tdd`, `$eng-review`, `$qa`, or `$verification` when the user -asks for any of: - -- `implementation-notes.md` -- `implementation-notes.html` -- running implementation notes -- decisions the spec did not cover -- deviations from the spec -- tradeoffs made during implementation -- open questions to confirm after implementation - -Do not ask whether to create the file if the user already requested it. Create or -update the requested file and keep working. - -## File Selection - -- Use the exact path and format the user requested. -- If the user asks for notes but does not name a file, use `implementation-notes.md`. -- If the user asks for HTML, use `implementation-notes.html`. -- If an implementation-notes file already exists for the current task, update it - instead of overwriting useful existing context. - -## Update Cadence - -1. Create the notes file before or during the first implementation decision. -2. Update it when the implementation makes a non-obvious choice, interprets an - ambiguous spec line, departs from the spec, accepts a tradeoff, discovers an - open question, or changes verification scope. -3. Batch small related choices into one entry instead of writing noisy micro-logs. -4. Before claiming completion, do a final pass that aligns notes with the actual - diff, verification evidence, and unresolved questions. - -## What To Capture - -### Design Decisions - -Choices made where the spec was ambiguous or silent. - -Each entry should include: - -- decision -- reason -- spec basis, or `unspecified` -- impact - -### Deviations - -Intentional departures from the spec. - -Each entry should include: - -- requested behavior -- implemented behavior -- reason -- impact -- whether user confirmation is needed - -### Tradeoffs - -Alternatives considered and why the chosen path is better for this slice. - -Each entry should include: - -- chosen option -- alternatives considered -- why chosen -- cost or downside accepted - -### Open Questions - -Questions the user may want to confirm or revise. - -Each entry should include: - -- question -- why it matters -- current default assumption -- status: `needs-review`, `accepted-risk`, `resolved`, or `deferred` - -### Verification - -Evidence that proves the implementation and the notes are current. - -Include: - -- commands or checks run -- result -- coverage gaps -- behavior not tested - -## What Not To Capture - -- Every file edit. -- Internal reasoning or chain-of-thought. -- Obvious implementation details already specified. -- Secrets, credentials, private customer data, or raw logs with sensitive content. -- Generic progress narration that does not help the user review decisions. - -## Markdown Template - -Use this structure for Markdown notes: - -```markdown -# Implementation Notes - -## Spec Reference -[Feature, ticket, prompt, or artifact being implemented.] - -## Summary -[One paragraph describing how the implementation interprets the spec.] - -## Design Decisions -| Decision | Reason | Spec basis | Impact | -|---|---|---|---| - -## Deviations -| Requested | Implemented | Why | Impact | Confirmation | -|---|---|---|---|---| - -## Tradeoffs -| Choice | Alternatives | Why this path | Downside | -|---|---|---|---| - -## Open Questions -| Question | Why it matters | Current assumption | Status | -|---|---|---|---| - -## Verification -| Check | Result | Notes | -|---|---|---| -``` - -## HTML Template Rules - -For `implementation-notes.html`, produce a single self-contained HTML file: - -- embedded CSS and JavaScript only -- no external assets or remote dependencies unless explicitly requested -- semantic headings and landmarks -- responsive layout -- decision cards or tables for scanability -- status chips for `needs-review`, `accepted-risk`, `resolved`, and `deferred` -- a clear verification section near the bottom -- optional filters, collapsible detail, or copy buttons only when they help review - -Recommended HTML sections: - -1. **Header**: spec reference, implementation status, last updated, owner if known. -2. **Decision Dashboard**: counts for decisions, deviations, tradeoffs, open questions. -3. **Design Decisions**: cards or table with reason, spec basis, and impact. -4. **Deviations**: requested vs implemented, why, impact, confirmation status. -5. **Tradeoffs**: comparison table with accepted downside. -6. **Open Questions**: status and current default assumption. -7. **Verification**: commands/checks, results, and gaps. - -## Route Internally - -- `$tdd` -- `$eng-review` -- `$qa` -- `$verification` -- `$docs` -- `$release` - -## Required Output - -Return: - -1. **Notes File**: path, format, and whether it was created or updated. -2. **Captured Decisions**: decisions, deviations, tradeoffs, and open questions added. -3. **Spec Impact**: what downstream product, design, eng, QA, release, docs, or DX work may change. -4. **Verification Linkage**: checks run, gaps, and whether the notes match the final implementation. -5. **Next Review**: user confirmations or gate follow-ups needed. diff --git a/skills/implementation-notes/SKILL.md.tmpl b/skills/implementation-notes/SKILL.md.tmpl deleted file mode 100644 index 039a22c9..00000000 --- a/skills/implementation-notes/SKILL.md.tmpl +++ /dev/null @@ -1,193 +0,0 @@ ---- -name: implementation-notes -description: >- - Running implementation-notes protocol for spec-driven builds. Use when the user - asks the agent to maintain implementation-notes.md or implementation-notes.html - with decisions, deviations, tradeoffs, open questions, and verification while - implementing a feature, fix, or product slice. ---- -# Implementation Notes - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when implementation work needs a durable notes artifact that keeps -the user in the loop without stopping progress for every ambiguity. - -This is not a verbose work log. It records the meaningful places where the spec -was interpreted, narrowed, changed, or found incomplete. - -## Activation - -Activate alongside `$tdd`, `$eng-review`, `$qa`, or `$verification` when the user -asks for any of: - -- `implementation-notes.md` -- `implementation-notes.html` -- running implementation notes -- decisions the spec did not cover -- deviations from the spec -- tradeoffs made during implementation -- open questions to confirm after implementation - -Do not ask whether to create the file if the user already requested it. Create or -update the requested file and keep working. - -## File Selection - -- Use the exact path and format the user requested. -- If the user asks for notes but does not name a file, use `implementation-notes.md`. -- If the user asks for HTML, use `implementation-notes.html`. -- If an implementation-notes file already exists for the current task, update it - instead of overwriting useful existing context. - -## Update Cadence - -1. Create the notes file before or during the first implementation decision. -2. Update it when the implementation makes a non-obvious choice, interprets an - ambiguous spec line, departs from the spec, accepts a tradeoff, discovers an - open question, or changes verification scope. -3. Batch small related choices into one entry instead of writing noisy micro-logs. -4. Before claiming completion, do a final pass that aligns notes with the actual - diff, verification evidence, and unresolved questions. - -## What To Capture - -### Design Decisions - -Choices made where the spec was ambiguous or silent. - -Each entry should include: - -- decision -- reason -- spec basis, or `unspecified` -- impact - -### Deviations - -Intentional departures from the spec. - -Each entry should include: - -- requested behavior -- implemented behavior -- reason -- impact -- whether user confirmation is needed - -### Tradeoffs - -Alternatives considered and why the chosen path is better for this slice. - -Each entry should include: - -- chosen option -- alternatives considered -- why chosen -- cost or downside accepted - -### Open Questions - -Questions the user may want to confirm or revise. - -Each entry should include: - -- question -- why it matters -- current default assumption -- status: `needs-review`, `accepted-risk`, `resolved`, or `deferred` - -### Verification - -Evidence that proves the implementation and the notes are current. - -Include: - -- commands or checks run -- result -- coverage gaps -- behavior not tested - -## What Not To Capture - -- Every file edit. -- Internal reasoning or chain-of-thought. -- Obvious implementation details already specified. -- Secrets, credentials, private customer data, or raw logs with sensitive content. -- Generic progress narration that does not help the user review decisions. - -## Markdown Template - -Use this structure for Markdown notes: - -```markdown -# Implementation Notes - -## Spec Reference -[Feature, ticket, prompt, or artifact being implemented.] - -## Summary -[One paragraph describing how the implementation interprets the spec.] - -## Design Decisions -| Decision | Reason | Spec basis | Impact | -|---|---|---|---| - -## Deviations -| Requested | Implemented | Why | Impact | Confirmation | -|---|---|---|---|---| - -## Tradeoffs -| Choice | Alternatives | Why this path | Downside | -|---|---|---|---| - -## Open Questions -| Question | Why it matters | Current assumption | Status | -|---|---|---|---| - -## Verification -| Check | Result | Notes | -|---|---|---| -``` - -## HTML Template Rules - -For `implementation-notes.html`, produce a single self-contained HTML file: - -- embedded CSS and JavaScript only -- no external assets or remote dependencies unless explicitly requested -- semantic headings and landmarks -- responsive layout -- decision cards or tables for scanability -- status chips for `needs-review`, `accepted-risk`, `resolved`, and `deferred` -- a clear verification section near the bottom -- optional filters, collapsible detail, or copy buttons only when they help review - -Recommended HTML sections: - -1. **Header**: spec reference, implementation status, last updated, owner if known. -2. **Decision Dashboard**: counts for decisions, deviations, tradeoffs, open questions. -3. **Design Decisions**: cards or table with reason, spec basis, and impact. -4. **Deviations**: requested vs implemented, why, impact, confirmation status. -5. **Tradeoffs**: comparison table with accepted downside. -6. **Open Questions**: status and current default assumption. -7. **Verification**: commands/checks, results, and gaps. - -## Route Internally - -- `$tdd` -- `$eng-review` -- `$qa` -- `$verification` -- `$docs` -- `$release` - -## Required Output - -Return: - -1. **Notes File**: path, format, and whether it was created or updated. -2. **Captured Decisions**: decisions, deviations, tradeoffs, and open questions added. -3. **Spec Impact**: what downstream product, design, eng, QA, release, docs, or DX work may change. -4. **Verification Linkage**: checks run, gaps, and whether the notes match the final implementation. -5. **Next Review**: user confirmations or gate follow-ups needed. diff --git a/skills/implementation-notes/agents/openai.yaml b/skills/implementation-notes/agents/openai.yaml deleted file mode 100644 index b317b975..00000000 --- a/skills/implementation-notes/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Implementation Notes" - short_description: "Running implementation-notes protocol for spec-driven builds. Use when the user asks the agent to maintain..." - brand_color: "#334155" - default_prompt: "Use $implementation-notes with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/implementation-notes/productize.json b/skills/implementation-notes/productize.json deleted file mode 100644 index 241fb910..00000000 --- a/skills/implementation-notes/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Implementation Notes", - "category": "AI Execution", - "lifecycle": "Build With AI", - "tags": [ - "implementation-notes", - "running-notes", - "spec-ambiguity", - "deviations", - "tradeoffs", - "open-questions", - "html-artifact", - "markdown-artifact", - "build-with-ai", - "agent-handoff", - "implementation", - "notes", - "execution", - "running" - ], - "use_when": "Use Implementation Notes when a spec-driven implementation needs a running notes artifact, especially implementation-notes.md or implementation-notes.html, that records decisions, deviations, tradeoffs, open questions, and verification while the agent builds.", - "do_not_use_when": "Do not use Implementation Notes for generic documentation, release notes, QA reports, architecture review, or stakeholder updates unless the primary need is to preserve implementation-time interpretations and spec deviations while code or product changes are being made.", - "output_artifact": "Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence", - "routing_signals": [ - "implementation-notes", - "running-implementation-notes", - "decisions-not-in-the-spec", - "spec-ambiguity", - "deviations-from-the-spec", - "tradeoffs-while-implementing", - "open-questions-while-implementing", - "implementation-notes-html", - "implementation-notes-md", - "implementation", - "notes", - "execution", - "running", - "protocol" - ], - "framework_fit": "Implementation Notes fits Build With AI work when an agent needs permission to make reasonable implementation decisions while preserving a reviewable record of how the final behavior interprets, narrows, or departs from the source spec.", - "failure_modes": [ - "Turns into a verbose activity journal that logs every file edit instead of the few decisions, deviations, tradeoffs, and open questions the user needs to review.", - "Creates a polished notes artifact only at the end and misses implementation-time ambiguity, causing the final report to hide why key choices were made.", - "Records internal reasoning, secrets, or generic progress narration instead of concise reviewable decisions tied to the spec and verification evidence." - ], - "examples": [ - { - "prompt": "Use $implementation-notes while implementing this spec and maintain implementation-notes.html with decisions, deviations, tradeoffs, open questions, and verification.", - "expected_artifact": "Implementation-notes decision log with spec interpretations, deviations, tradeoffs, open questions, and verification evidence" - } - ] -} diff --git a/skills/industry-trend-strategy/SKILL.md b/skills/industry-trend-strategy/SKILL.md deleted file mode 100644 index becc8af7..00000000 --- a/skills/industry-trend-strategy/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: industry-trend-strategy -description: >- - Industry trend strategy. Use when the user needs a product workflow for product strategy - related to industry trend strategy. Trigger terms: strategy, competitive-analysis, - positioning, decision-making. ---- - - - -# Industry trend strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `industry-trend-strategy` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Industry trend strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INDUSTRY}} -- {{TREND}} -- {{COMPANY}} -- {{GOAL}} - - -GOAL -Produce a high-quality deliverable for: Industry trend strategy. -Success metric: -- Produces a grounded industry + trend analysis tied to company strengths and goal. -- Proposes at least three distinct strategies with actionable steps. -- Summarizes how strategies leverage strengths to achieve the goal. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{INDUSTRY}}`, `{{TREND}}`, `{{COMPANY}}`, and `{{GOAL}}`; if critical data is missing, state assumptions explicitly. -- Provide a concise industry + trend analysis and a focused company strengths assessment. -- Propose at least 3 distinct strategies aligned to strengths and goal. -- Each strategy must include name, description, alignment, contribution to goal, challenges, and action steps. -- Keep recommendations specific and actionable, not generic. - -FORMAT -Return exactly this structure: - - -[Industry + trend analysis and company strength assessment] - - - -1. [Strategy name] - - Description: [What it is] - - Alignment: [Company strengths leveraged] - - Contribution to goal: [How it advances the goal] - - Challenges: [Risks/obstacles] - - Action steps: [Concrete steps] -2. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -3. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -[Optional additional strategies] - - - -[Summary emphasizing how strategies leverage strengths to capitalize on the trend and achieve the goal] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 strategies are provided. -- Strategies lack alignment to company strengths or contribution to goal. -- Action steps are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/industry-trend-strategy/SKILL.md.tmpl b/skills/industry-trend-strategy/SKILL.md.tmpl deleted file mode 100644 index 52546047..00000000 --- a/skills/industry-trend-strategy/SKILL.md.tmpl +++ /dev/null @@ -1,86 +0,0 @@ ---- -name: industry-trend-strategy -description: >- - Industry trend strategy. Use when the user needs a product workflow for product strategy - related to industry trend strategy. Trigger terms: strategy, competitive-analysis, - positioning, decision-making. ---- -# Industry trend strategy - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Industry trend strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INDUSTRY}} -- {{TREND}} -- {{COMPANY}} -- {{GOAL}} - - -GOAL -Produce a high-quality deliverable for: Industry trend strategy. -Success metric: -- Produces a grounded industry + trend analysis tied to company strengths and goal. -- Proposes at least three distinct strategies with actionable steps. -- Summarizes how strategies leverage strengths to achieve the goal. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{INDUSTRY}}`, `{{TREND}}`, `{{COMPANY}}`, and `{{GOAL}}`; if critical data is missing, state assumptions explicitly. -- Provide a concise industry + trend analysis and a focused company strengths assessment. -- Propose at least 3 distinct strategies aligned to strengths and goal. -- Each strategy must include name, description, alignment, contribution to goal, challenges, and action steps. -- Keep recommendations specific and actionable, not generic. - -FORMAT -Return exactly this structure: - - -[Industry + trend analysis and company strength assessment] - - - -1. [Strategy name] - - Description: [What it is] - - Alignment: [Company strengths leveraged] - - Contribution to goal: [How it advances the goal] - - Challenges: [Risks/obstacles] - - Action steps: [Concrete steps] -2. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -3. [Strategy name] - - Description: ... - - Alignment: ... - - Contribution to goal: ... - - Challenges: ... - - Action steps: ... -[Optional additional strategies] - - - -[Summary emphasizing how strategies leverage strengths to capitalize on the trend and achieve the goal] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 strategies are provided. -- Strategies lack alignment to company strengths or contribution to goal. -- Action steps are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/industry-trend-strategy/agents/openai.yaml b/skills/industry-trend-strategy/agents/openai.yaml deleted file mode 100644 index c502b7b3..00000000 --- a/skills/industry-trend-strategy/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Industry trend strategy" - short_description: "Industry trend strategy. Use when the user needs a product workflow for product strategy related to industry trend..." - brand_color: "#EA580C" - default_prompt: "Use $industry-trend-strategy with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/industry-trend-strategy/productize.json b/skills/industry-trend-strategy/productize.json deleted file mode 100644 index 91de3647..00000000 --- a/skills/industry-trend-strategy/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Industry trend strategy", - "category": "Marketing", - "lifecycle": "Strategize", - "tags": [ - "industry-trend-strategy", - "industry", - "trend", - "use", - "needs", - "workflow", - "marketing" - ], - "use_when": "Industry trend strategy. Use when the user needs a product workflow for product strategy related to industry trend strategy. Trigger terms: strategy, competitive-analysis, positioning, decision-making.", - "do_not_use_when": "Do not use Industry trend strategy when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "industry-trend-strategy", - "industry", - "trend", - "use", - "needs", - "workflow", - "marketing" - ], - "framework_fit": "Industry trend strategy fits Marketing work in the Strategize lifecycle when the user needs Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Industry trend strategy as generic Marketing advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Industry trend strategy when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $industry-trend-strategy to turn this industry context into a decision-ready Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Industry trend strategy strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md b/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md deleted file mode 100644 index 8339ff15..00000000 --- a/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: influence-strategies-from-cialdini-s-7-principles -description: >- - Influence strategies from Cialdini's 7 principles. Use when the user needs a product - workflow for stakeholder management related to influence strategies from cialdini's 7 - principles. Trigger terms: influence, cialdini, stakeholder-management. ---- - - - -# Influence strategies from Cialdini's 7 principles - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `influence-strategies-from-cialdini-s-7-principles` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Influence strategies from Cialdini's 7 principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INFLUENCE_TARGET}} -- {{INFLUENCE_GOAL}} - - -GOAL -Produce a high-quality deliverable for: Influence strategies from Cialdini's 7 principles. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate influence ideas tailored to `{{INFLUENCE_TARGET}}` and `{{INFLUENCE_GOAL}}`. -- Provide at least one specific, actionable, ethical idea for each Cialdini principle: -- Reciprocity -- Liking -- Unity -- Authority -- Social Proof -- Consistency -- Scarcity -- For each idea, include a clear strategy and rationale tied to the target context and goal. -- Use professional, non-manipulative tactics that create value for both sides. - -FORMAT -Return exactly this structure: - - - -Name of the principle -Detailed description of the strategy or tactic -Explanation of why this idea would be effective for the given target and goal - -(Repeat this structure for each of the seven principles) - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Not all seven principles are covered, or principles are duplicated while another is missing. -- Strategies are generic, unethical/manipulative, or not tied to the target and goal. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md.tmpl b/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md.tmpl deleted file mode 100644 index d330338d..00000000 --- a/skills/influence-strategies-from-cialdini-s-7-principles/SKILL.md.tmpl +++ /dev/null @@ -1,70 +0,0 @@ ---- -name: influence-strategies-from-cialdini-s-7-principles -description: >- - Influence strategies from Cialdini's 7 principles. Use when the user needs a product - workflow for stakeholder management related to influence strategies from cialdini's 7 - principles. Trigger terms: influence, cialdini, stakeholder-management. ---- -# Influence strategies from Cialdini's 7 principles - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Influence strategies from Cialdini's 7 principles**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{INFLUENCE_TARGET}} -- {{INFLUENCE_GOAL}} - - -GOAL -Produce a high-quality deliverable for: Influence strategies from Cialdini's 7 principles. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Generate influence ideas tailored to `{{INFLUENCE_TARGET}}` and `{{INFLUENCE_GOAL}}`. -- Provide at least one specific, actionable, ethical idea for each Cialdini principle: -- Reciprocity -- Liking -- Unity -- Authority -- Social Proof -- Consistency -- Scarcity -- For each idea, include a clear strategy and rationale tied to the target context and goal. -- Use professional, non-manipulative tactics that create value for both sides. - -FORMAT -Return exactly this structure: - - - -Name of the principle -Detailed description of the strategy or tactic -Explanation of why this idea would be effective for the given target and goal - -(Repeat this structure for each of the seven principles) - - -FAILURE -- `` schema is missing, malformed, or materially incomplete. -- Not all seven principles are covered, or principles are duplicated while another is missing. -- Strategies are generic, unethical/manipulative, or not tied to the target and goal. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/influence-strategies-from-cialdini-s-7-principles/agents/openai.yaml b/skills/influence-strategies-from-cialdini-s-7-principles/agents/openai.yaml deleted file mode 100644 index 6af0c016..00000000 --- a/skills/influence-strategies-from-cialdini-s-7-principles/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Influence strategies from Cialdini's 7 principles" - short_description: "Influence strategies from Cialdini's 7 principles. Use when the user needs a product workflow for stakeholder..." - brand_color: "#0891B2" - default_prompt: "Use $influence-strategies-from-cialdini-s-7-principles with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/influence-strategies-from-cialdini-s-7-principles/productize.json b/skills/influence-strategies-from-cialdini-s-7-principles/productize.json deleted file mode 100644 index 021b768a..00000000 --- a/skills/influence-strategies-from-cialdini-s-7-principles/productize.json +++ /dev/null @@ -1,40 +0,0 @@ -{ - "title": "Influence strategies from Cialdini's 7 principles", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "influence-strategies-from-cialdini-s-7-principles", - "influence", - "strategies", - "cialdini", - "principles", - "stakeholder", - "management", - "communication" - ], - "use_when": "Influence strategies from Cialdini's 7 principles. Use when the user needs a product workflow for stakeholder management related to influence strategies from cialdini's 7 principles. Trigger terms: influence, cialdini, stakeholder-management.", - "do_not_use_when": "Do not use Influence strategies from Cialdini's 7 principles when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "influence-strategies-from-cialdini-s-7-principles", - "influence", - "strategies", - "cialdini", - "principles", - "stakeholder", - "management", - "communication" - ], - "framework_fit": "Influence strategies from Cialdini's 7 principles fits Stakeholder Communication work in the Align lifecycle when the user needs Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Influence strategies from Cialdini's 7 principles as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Influence strategies from Cialdini's 7 principles when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $influence-strategies-from-cialdini-s-7-principles to turn this influence context into a decision-ready Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Influence strategies from Cialdini's 7 principles stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/innovation-decision-making-heuristics/SKILL.md b/skills/innovation-decision-making-heuristics/SKILL.md deleted file mode 100644 index d62f1950..00000000 --- a/skills/innovation-decision-making-heuristics/SKILL.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -name: innovation-decision-making-heuristics -description: >- - Design tailored decision-making heuristics for uncertain innovation work. Use when the user - needs simple decision rules for product bets, discovery, investment, pivot, prioritization, - or opportunity selection in noisy and changing contexts. ---- - - - -# Innovation Decision Making Heuristics - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovation-decision-making-heuristics` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop - -Use this skill when a team needs a practical decision rule, not a one-off recommendation. -The output should help the team decide repeatedly under uncertainty while avoiding arbitrary -or off-the-shelf rules. - -## Decision-Making Principles - -- Heuristics are useful shortcuts when the environment is noisy, dynamic, uncertain, or - time-sensitive and more information does not necessarily clarify direction. -- Heuristics fail when applied blindly, when nuance matters, or when the environment is stable - enough for more complete analysis. -- Effective heuristics should come from the user's real business challenge, constraints, - evidence, and observed feedback. -- A good heuristic makes tradeoffs explicit: speed versus accuracy, exploration versus focus, - safety versus moonshot, and learning versus commitment. -- Heuristics must be reviewed and refined through practical experience. - -## Workflow - -1. Identify the recurring decision type and the context in which it appears. -2. Classify the environment: noisy/dynamic/uncertain, stable, time-sensitive, multi-factor, - politically loaded, or high-stakes irreversible. -3. Define what the heuristic should optimize: learning, speed, risk control, focus, upside, - user value, revenue, retention, or strategic fit. -4. Identify where naive heuristics could fail. -5. Create 3-5 tailored decision rules with explicit triggers and exceptions. -6. Add a feedback loop so the rule can improve after use. - -## Output Contract - -Return: - -```markdown -# Innovation Decision Making Heuristics - -## 1. Recurring Decision -Decision type: -Who decides: -Frequency: -Time pressure: -Stakes: - -## 2. Decision Environment -Context: -Noise / uncertainty: -Information quality: -Reversibility: -Stable analysis possible: - -## 3. What The Rules Should Optimize -Primary objective: -Secondary objective: -Tradeoff to accept: -Tradeoff to avoid: - -## 4. Heuristic Failure Risks -Where shortcuts help: -Where shortcuts fail: -Bias risks: -Escalation or sunk-cost risk: - -## 5. Tailored Decision Rules -Rule 1: -Use when: -Exception: -Evidence needed: - -Rule 2: -Use when: -Exception: -Evidence needed: - -Rule 3: -Use when: -Exception: -Evidence needed: - -## 6. Feedback And Refinement -Signal to track: -Review cadence: -Who updates the rule: -When to retire the rule: -``` - -## Failure Modes - -- Provides generic principles instead of concrete decision rules. -- Creates rules that ignore the user's actual uncertainty, constraints, and feedback loops. -- Treats heuristics as always good or always bad rather than context-dependent. -- Omits exceptions and review mechanisms. diff --git a/skills/innovation-decision-making-heuristics/SKILL.md.tmpl b/skills/innovation-decision-making-heuristics/SKILL.md.tmpl deleted file mode 100644 index 59c1e5aa..00000000 --- a/skills/innovation-decision-making-heuristics/SKILL.md.tmpl +++ /dev/null @@ -1,100 +0,0 @@ ---- -name: innovation-decision-making-heuristics -description: >- - Design tailored decision-making heuristics for uncertain innovation work. Use when the user - needs simple decision rules for product bets, discovery, investment, pivot, prioritization, - or opportunity selection in noisy and changing contexts. ---- -# Innovation Decision Making Heuristics - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when a team needs a practical decision rule, not a one-off recommendation. -The output should help the team decide repeatedly under uncertainty while avoiding arbitrary -or off-the-shelf rules. - -## Decision-Making Principles - -- Heuristics are useful shortcuts when the environment is noisy, dynamic, uncertain, or - time-sensitive and more information does not necessarily clarify direction. -- Heuristics fail when applied blindly, when nuance matters, or when the environment is stable - enough for more complete analysis. -- Effective heuristics should come from the user's real business challenge, constraints, - evidence, and observed feedback. -- A good heuristic makes tradeoffs explicit: speed versus accuracy, exploration versus focus, - safety versus moonshot, and learning versus commitment. -- Heuristics must be reviewed and refined through practical experience. - -## Workflow - -1. Identify the recurring decision type and the context in which it appears. -2. Classify the environment: noisy/dynamic/uncertain, stable, time-sensitive, multi-factor, - politically loaded, or high-stakes irreversible. -3. Define what the heuristic should optimize: learning, speed, risk control, focus, upside, - user value, revenue, retention, or strategic fit. -4. Identify where naive heuristics could fail. -5. Create 3-5 tailored decision rules with explicit triggers and exceptions. -6. Add a feedback loop so the rule can improve after use. - -## Output Contract - -Return: - -```markdown -# Innovation Decision Making Heuristics - -## 1. Recurring Decision -Decision type: -Who decides: -Frequency: -Time pressure: -Stakes: - -## 2. Decision Environment -Context: -Noise / uncertainty: -Information quality: -Reversibility: -Stable analysis possible: - -## 3. What The Rules Should Optimize -Primary objective: -Secondary objective: -Tradeoff to accept: -Tradeoff to avoid: - -## 4. Heuristic Failure Risks -Where shortcuts help: -Where shortcuts fail: -Bias risks: -Escalation or sunk-cost risk: - -## 5. Tailored Decision Rules -Rule 1: -Use when: -Exception: -Evidence needed: - -Rule 2: -Use when: -Exception: -Evidence needed: - -Rule 3: -Use when: -Exception: -Evidence needed: - -## 6. Feedback And Refinement -Signal to track: -Review cadence: -Who updates the rule: -When to retire the rule: -``` - -## Failure Modes - -- Provides generic principles instead of concrete decision rules. -- Creates rules that ignore the user's actual uncertainty, constraints, and feedback loops. -- Treats heuristics as always good or always bad rather than context-dependent. -- Omits exceptions and review mechanisms. diff --git a/skills/innovation-decision-making-heuristics/agents/openai.yaml b/skills/innovation-decision-making-heuristics/agents/openai.yaml deleted file mode 100644 index 0b0083c1..00000000 --- a/skills/innovation-decision-making-heuristics/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovation Decision Making Heuristics" - short_description: "Design tailored decision-making heuristics for uncertain innovation work. Use when the user needs simple decision..." - brand_color: "#7C2D12" - default_prompt: "Use $innovation-decision-making-heuristics with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/innovation-decision-making-heuristics/productize.json b/skills/innovation-decision-making-heuristics/productize.json deleted file mode 100644 index c0044026..00000000 --- a/skills/innovation-decision-making-heuristics/productize.json +++ /dev/null @@ -1,51 +0,0 @@ -{ - "title": "Innovation Decision Making Heuristics", - "category": "Decision Making", - "lifecycle": "Think", - "tags": [ - "innovation-decision-making", - "heuristics", - "simple-rules", - "decision-rules", - "uncertainty", - "noisy-context", - "time-pressure", - "innovation-bets", - "pivot-rules", - "innovation-decision-making-heuristics", - "innovation", - "decision", - "making" - ], - "use_when": "Use when a founder, PM, product leader, or innovation team needs tailored simple rules for recurring product, innovation, discovery, investment, opportunity, pivot, or prioritization decisions under uncertainty.", - "do_not_use_when": "Do not use for a one-off strategic decision review, formal prioritization scoring, or launch risk pre-mortem unless the user explicitly needs reusable decision rules.", - "output_artifact": "Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop", - "routing_signals": [ - "innovation-heuristics", - "decision-heuristics", - "decision-rules", - "simple-rules", - "rules-of-thumb", - "noisy-uncertain-decision", - "time-sensitive-decision", - "pivot-rule", - "innovation-bets", - "tailored-heuristic", - "innovation-decision-making-heuristics", - "innovation", - "decision", - "making" - ], - "framework_fit": "Best when the team faces repeated uncertain innovation decisions and needs explicit rules that can be refined through feedback.", - "failure_modes": [ - "Produces Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Innovation Decision Making Heuristics as generic Decision Making advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Innovation Decision Making Heuristics when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $innovation-decision-making-heuristics to create rules for when our AI product team should pivot a discovery bet, keep testing, or stop.", - "expected_artifact": "Innovation decision-making heuristic playbook with context fit, tailored rules, exceptions, and feedback loop" - } - ] -} diff --git a/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md b/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md deleted file mode 100644 index 37bbe578..00000000 --- a/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: innovative-idea-generation-from-project-parameters-and -description: >- - Innovative idea generation from project parameters and constraints. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, - product-management, osborn-checklist. ---- - - - -# Innovative idea generation from project parameters and constraints - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-project-parameters-and` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from project parameters and constraints**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_TYPE}} -- {{GOALS}} -- {{BUDGET}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from project parameters and constraints". -Success metric: -- Produces concrete, non-generic ideas that fit project type, goals, and budget. -- Uses structured creativity analysis (including Osborn checklist) to move beyond obvious solutions. -- Final ideas are immediately actionable with clear execution steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_TYPE}}`, `{{GOALS}}`, and `{{BUDGET}}`; if details are missing, state assumptions explicitly. -- Provide exactly 5 banal ideas to avoid and explain why each is weak. -- Define problem context including timeframe, target audience, and situation. -- Break down problem into objective, constraints, measurable success criteria, challenges, and deeper considerations. -- Analyze each chunk with explicit link to goals and budget feasibility. -- Include both creator and consumer perspectives. -- Apply Osborn checklist categories with project-relevant outputs: - - other uses, adaptations, modifications, magnification, minification, substitutions, rearrangements, reversals, combinations. -- Final ideas must be actionable for an individual, feasible under budget, and include step-by-step instructions plus application context. - -FORMAT -Return exactly this structure: - - - -1. [Banal idea] - [Why to avoid] -2. [Banal idea] - [Why to avoid] -3. [Banal idea] - [Why to avoid] -4. [Banal idea] - [Why to avoid] -5. [Banal idea] - [Why to avoid] - - - -[Clearly define the problem or situation] - - - -[Break down the problem into key aspects] - - - -[Provide in-depth analysis of each problem chunk] - - - -[Describe creator and consumer perspectives] - - - -- Other uses: [Ideas] -- Adaptations: [Ideas] -- Modifications: [Ideas] -- Magnification: [Ideas] -- Minification: [Ideas] -- Substitutions: [Ideas] -- Rearrangements: [Ideas] -- Reversals: [Ideas] -- Combinations: [Ideas] - - - -1. [Idea title] - - Specific guidance: [What to do] - - Steps: [Step-by-step] - - Where/how to apply: [Context/channel/tool] - - Budget fit: [How it stays within budget] -[Repeat for additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `banal_ideas` does not contain exactly 5 items. -- One or more Osborn checklist categories are missing. -- Final ideas are not actionable step-by-step or are not aligned to budget/goals. -- Output is generic or repeats clichรฉ ideas without meaningful differentiation. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md.tmpl b/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md.tmpl deleted file mode 100644 index e0ce0600..00000000 --- a/skills/innovative-idea-generation-from-project-parameters-and/SKILL.md.tmpl +++ /dev/null @@ -1,108 +0,0 @@ ---- -name: innovative-idea-generation-from-project-parameters-and -description: >- - Innovative idea generation from project parameters and constraints. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, - product-management, osborn-checklist. ---- -# Innovative idea generation from project parameters and constraints - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Innovative idea generation from project parameters and constraints**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROJECT_TYPE}} -- {{GOALS}} -- {{BUDGET}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from project parameters and constraints". -Success metric: -- Produces concrete, non-generic ideas that fit project type, goals, and budget. -- Uses structured creativity analysis (including Osborn checklist) to move beyond obvious solutions. -- Final ideas are immediately actionable with clear execution steps. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROJECT_TYPE}}`, `{{GOALS}}`, and `{{BUDGET}}`; if details are missing, state assumptions explicitly. -- Provide exactly 5 banal ideas to avoid and explain why each is weak. -- Define problem context including timeframe, target audience, and situation. -- Break down problem into objective, constraints, measurable success criteria, challenges, and deeper considerations. -- Analyze each chunk with explicit link to goals and budget feasibility. -- Include both creator and consumer perspectives. -- Apply Osborn checklist categories with project-relevant outputs: - - other uses, adaptations, modifications, magnification, minification, substitutions, rearrangements, reversals, combinations. -- Final ideas must be actionable for an individual, feasible under budget, and include step-by-step instructions plus application context. - -FORMAT -Return exactly this structure: - - - -1. [Banal idea] - [Why to avoid] -2. [Banal idea] - [Why to avoid] -3. [Banal idea] - [Why to avoid] -4. [Banal idea] - [Why to avoid] -5. [Banal idea] - [Why to avoid] - - - -[Clearly define the problem or situation] - - - -[Break down the problem into key aspects] - - - -[Provide in-depth analysis of each problem chunk] - - - -[Describe creator and consumer perspectives] - - - -- Other uses: [Ideas] -- Adaptations: [Ideas] -- Modifications: [Ideas] -- Magnification: [Ideas] -- Minification: [Ideas] -- Substitutions: [Ideas] -- Rearrangements: [Ideas] -- Reversals: [Ideas] -- Combinations: [Ideas] - - - -1. [Idea title] - - Specific guidance: [What to do] - - Steps: [Step-by-step] - - Where/how to apply: [Context/channel/tool] - - Budget fit: [How it stays within budget] -[Repeat for additional ideas] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `banal_ideas` does not contain exactly 5 items. -- One or more Osborn checklist categories are missing. -- Final ideas are not actionable step-by-step or are not aligned to budget/goals. -- Output is generic or repeats clichรฉ ideas without meaningful differentiation. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/innovative-idea-generation-from-project-parameters-and/agents/openai.yaml b/skills/innovative-idea-generation-from-project-parameters-and/agents/openai.yaml deleted file mode 100644 index b82b24cb..00000000 --- a/skills/innovative-idea-generation-from-project-parameters-and/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovative idea generation from project parameters and constraints" - short_description: "Innovative idea generation from project parameters and constraints. Use when the user needs a product workflow for..." - brand_color: "#0D9488" - default_prompt: "Use $innovative-idea-generation-from-project-parameters-and with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/innovative-idea-generation-from-project-parameters-and/productize.json b/skills/innovative-idea-generation-from-project-parameters-and/productize.json deleted file mode 100644 index 564f6dbd..00000000 --- a/skills/innovative-idea-generation-from-project-parameters-and/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Innovative idea generation from project parameters and constraints", - "category": "Discovery", - "lifecycle": "Think", - "tags": [ - "innovative-idea-generation-from-project-parameters-and", - "innovative", - "idea", - "generation", - "project", - "parameters" - ], - "use_when": "Innovative idea generation from project parameters and constraints. Use when the user needs a product workflow for ideation & creativity related to innovative idea generation from project parameters and constraints. Trigger terms: creativity, idea-generation, constraints, product-management, osborn-checklist.", - "do_not_use_when": "Do not use Innovative idea generation from project parameters and constraints when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action", - "routing_signals": [ - "innovative-idea-generation-from-project-parameters-and", - "innovative", - "idea", - "generation", - "project", - "parameters" - ], - "framework_fit": "Innovative idea generation from project parameters and constraints fits Discovery work in the Think lifecycle when the user needs Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Innovative idea generation from project parameters and constraints as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Innovative idea generation from project parameters and constraints when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $innovative-idea-generation-from-project-parameters-and to turn this innovative context into a decision-ready Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action.", - "expected_artifact": "Innovative idea generation from project parameters and constraints product artifact with evidence, risks, recommendation, and next action" - } - ] -} diff --git a/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md b/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 9f67111a..00000000 --- a/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -name: innovative-idea-generation-from-structured-brainstorming -description: >- - Innovative idea generation from structured brainstorming techniques. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, - creativity, product-discovery, problem-solving. ---- - - - -# Innovative idea generation from structured brainstorming techniques - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-idea-generation-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative idea generation from structured brainstorming techniques**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from structured brainstorming techniques". -Success metric: -- Produces a structured ideation session using free association, mind mapping, SCAMPER, and bias checks. -- Generates non-obvious, high-potential ideas grounded in the topic. -- Outputs clear top ideas with rationale and a concise synthesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run a complete structured ideation flow: - - free association (4-6 rounds), - - mind map (3-4 levels), - - SCAMPER exploration (2-3 rounds across shortlisted branches), - - bias check, - - top-idea selection and rationale. -- Avoid clichรฉd or overhyped ideas; prioritize specificity and novelty. -- Ensure top ideas are distinct from one another and clearly connected to generated branches. -- Keep outputs practical enough to be explored/prototyped next. - -FORMAT -Return exactly this structure: - - - -[4-6 rounds of free associations tied to `{{TOPIC}}`] - - - -[Mind map with 3-4 branching levels derived from free associations] - - - -1. [Branch] -2. [Branch] -3. [Branch] - - - -[2-3 rounds applying SCAMPER prompts to shortlisted branches] - - - -- Anchoring check: [Findings/adjustment] -- Status quo check: [Findings/adjustment] -- Groupthink check: [Findings/adjustment] - - - -1. [Idea 1] -2. [Idea 2] -3. [Idea 3] - - - -1. [Why idea 1 is powerful and non-obvious] -2. [Why idea 2 is powerful and non-obvious] -3. [Why idea 3 is powerful and non-obvious] - - - - -1. [Idea 1]: [Rationale] -2. [Idea 2]: [Rationale] -3. [Idea 3]: [Rationale] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `freeassociation` has fewer than 4 rounds or more than 6 rounds. -- `mindmap` does not show 3-4 levels of branching. -- `scamper` does not include at least 2 rounds. -- `top_ideas` does not contain exactly 3 distinct ideas. -- Rationales are generic and do not explain non-obvious value. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md.tmpl b/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md.tmpl deleted file mode 100644 index 38359c41..00000000 --- a/skills/innovative-idea-generation-from-structured-brainstorming/SKILL.md.tmpl +++ /dev/null @@ -1,105 +0,0 @@ ---- -name: innovative-idea-generation-from-structured-brainstorming -description: >- - Innovative idea generation from structured brainstorming techniques. Use when the user needs - a product workflow for ideation & creativity related to innovative idea generation from - structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, - creativity, product-discovery, problem-solving. ---- -# Innovative idea generation from structured brainstorming techniques - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Innovative idea generation from structured brainstorming techniques**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative idea generation from structured brainstorming techniques". -Success metric: -- Produces a structured ideation session using free association, mind mapping, SCAMPER, and bias checks. -- Generates non-obvious, high-potential ideas grounded in the topic. -- Outputs clear top ideas with rationale and a concise synthesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run a complete structured ideation flow: - - free association (4-6 rounds), - - mind map (3-4 levels), - - SCAMPER exploration (2-3 rounds across shortlisted branches), - - bias check, - - top-idea selection and rationale. -- Avoid clichรฉd or overhyped ideas; prioritize specificity and novelty. -- Ensure top ideas are distinct from one another and clearly connected to generated branches. -- Keep outputs practical enough to be explored/prototyped next. - -FORMAT -Return exactly this structure: - - - -[4-6 rounds of free associations tied to `{{TOPIC}}`] - - - -[Mind map with 3-4 branching levels derived from free associations] - - - -1. [Branch] -2. [Branch] -3. [Branch] - - - -[2-3 rounds applying SCAMPER prompts to shortlisted branches] - - - -- Anchoring check: [Findings/adjustment] -- Status quo check: [Findings/adjustment] -- Groupthink check: [Findings/adjustment] - - - -1. [Idea 1] -2. [Idea 2] -3. [Idea 3] - - - -1. [Why idea 1 is powerful and non-obvious] -2. [Why idea 2 is powerful and non-obvious] -3. [Why idea 3 is powerful and non-obvious] - - - - -1. [Idea 1]: [Rationale] -2. [Idea 2]: [Rationale] -3. [Idea 3]: [Rationale] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- `freeassociation` has fewer than 4 rounds or more than 6 rounds. -- `mindmap` does not show 3-4 levels of branching. -- `scamper` does not include at least 2 rounds. -- `top_ideas` does not contain exactly 3 distinct ideas. -- Rationales are generic and do not explain non-obvious value. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/innovative-idea-generation-from-structured-brainstorming/agents/openai.yaml b/skills/innovative-idea-generation-from-structured-brainstorming/agents/openai.yaml deleted file mode 100644 index 1dd826d7..00000000 --- a/skills/innovative-idea-generation-from-structured-brainstorming/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovative idea generation from structured brainstorming techniques" - short_description: "Innovative idea generation from structured brainstorming techniques. Use when the user needs a product workflow for..." - brand_color: "#0D9488" - default_prompt: "Use $innovative-idea-generation-from-structured-brainstorming with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/innovative-idea-generation-from-structured-brainstorming/productize.json b/skills/innovative-idea-generation-from-structured-brainstorming/productize.json deleted file mode 100644 index e6b8d0a9..00000000 --- a/skills/innovative-idea-generation-from-structured-brainstorming/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Innovative idea generation from structured brainstorming techniques", - "category": "Discovery", - "lifecycle": "Think", - "tags": [ - "innovative-idea-generation-from-structured-brainstorming", - "innovative", - "idea", - "generation", - "structured", - "brainstorming" - ], - "use_when": "Innovative idea generation from structured brainstorming techniques. Use when the user needs a product workflow for ideation & creativity related to innovative idea generation from structured brainstorming techniques. Trigger terms: brainstorming, structured-ideation, creativity, product-discovery, problem-solving.", - "do_not_use_when": "Do not use Innovative idea generation from structured brainstorming techniques when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action", - "routing_signals": [ - "innovative-idea-generation-from-structured-brainstorming", - "innovative", - "idea", - "generation", - "structured", - "brainstorming" - ], - "framework_fit": "Innovative idea generation from structured brainstorming techniques fits Discovery work in the Think lifecycle when the user needs Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Innovative idea generation from structured brainstorming techniques as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Innovative idea generation from structured brainstorming techniques when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $innovative-idea-generation-from-structured-brainstorming to turn this innovative context into a decision-ready Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action.", - "expected_artifact": "Innovative idea generation from structured brainstorming techniques product artifact with evidence, risks, recommendation, and next action" - } - ] -} diff --git a/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md b/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md deleted file mode 100644 index 5f02fe73..00000000 --- a/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -name: innovative-product-ideas-from-structured-brainstorming -description: >- - Innovative product ideas from structured brainstorming. Use when the user needs a product - workflow for ideation & creativity related to innovative product ideas from structured - brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, - product-management. ---- - - - -# Innovative product ideas from structured brainstorming - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `innovative-product-ideas-from-structured-brainstorming` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Innovative product ideas from structured brainstorming**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative product ideas from structured brainstorming". -Success metric: -- Produces a complete structured brainstorming session from divergence to convergence. -- Generates non-obvious product ideas grounded in the topic and validated via bias checks. -- Returns exactly 3 top ideas with clear innovation rationale in abstract terms. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run all stages: free association, mind map, SCAMPER expansion, bias check, top-idea selection, summary. -- Avoid banal, overhyped, or clichรฉd outputs. -- Top ideas must be described abstractly; do not use specific tech buzzwords such as `AI`, `blockchain`, or `VR`. -- Ensure ideas are distinct and traceable to earlier brainstorming artifacts. - -FORMAT -Return exactly this structure: - - - - -1. [Word or phrase] -2. [Word or phrase] -... -[Total 8-10 items] - - - -[Topic] -- [Main branch 1] - - [Sub-branch 1a] - - [Sub-branch 1b] -- [Main branch 2] - - [Sub-branch 2a] - - [Sub-branch 2b] -- [Main branch 3] - - [Sub-branch 3a] - - [Sub-branch 3b] -[At least 3 main branches; each with 2-3 sub-branches] - - - -- Branch: [Name] - - Technique 1: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] - - Technique 2: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] -[Repeat for 3 branches] - - - -- Bias: [Name] - - Evidence in ideas: [How it appears] - - Countermeasure: [Concrete action] -[At least 1 bias] - - - -1. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -2. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -3. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] - - - -[Brief recap of process and why final ideas are stronger after SCAMPER and bias checks] - - - - -FAILURE -- Root tag `` or any required sub-tag is missing, malformed, or incomplete. -- `free_association` has fewer than 8 or more than 10 items. -- `mind_map` has fewer than 3 main branches or insufficient sub-branches. -- `scamper` does not cover 3 branches with 2 techniques each. -- `top_ideas` does not contain exactly 3 ideas. -- Top ideas include banned specific-technology terms (`AI`, `blockchain`, `VR`). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md.tmpl b/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md.tmpl deleted file mode 100644 index 82a68f23..00000000 --- a/skills/innovative-product-ideas-from-structured-brainstorming/SKILL.md.tmpl +++ /dev/null @@ -1,120 +0,0 @@ ---- -name: innovative-product-ideas-from-structured-brainstorming -description: >- - Innovative product ideas from structured brainstorming. Use when the user needs a product - workflow for ideation & creativity related to innovative product ideas from structured - brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, - product-management. ---- -# Innovative product ideas from structured brainstorming - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Innovative product ideas from structured brainstorming**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TOPIC}} - - -GOAL -Produce a high-quality deliverable for: "Innovative product ideas from structured brainstorming". -Success metric: -- Produces a complete structured brainstorming session from divergence to convergence. -- Generates non-obvious product ideas grounded in the topic and validated via bias checks. -- Returns exactly 3 top ideas with clear innovation rationale in abstract terms. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TOPIC}}`; if scope is unclear, state assumptions explicitly. -- Run all stages: free association, mind map, SCAMPER expansion, bias check, top-idea selection, summary. -- Avoid banal, overhyped, or clichรฉd outputs. -- Top ideas must be described abstractly; do not use specific tech buzzwords such as `AI`, `blockchain`, or `VR`. -- Ensure ideas are distinct and traceable to earlier brainstorming artifacts. - -FORMAT -Return exactly this structure: - - - - -1. [Word or phrase] -2. [Word or phrase] -... -[Total 8-10 items] - - - -[Topic] -- [Main branch 1] - - [Sub-branch 1a] - - [Sub-branch 1b] -- [Main branch 2] - - [Sub-branch 2a] - - [Sub-branch 2b] -- [Main branch 3] - - [Sub-branch 3a] - - [Sub-branch 3b] -[At least 3 main branches; each with 2-3 sub-branches] - - - -- Branch: [Name] - - Technique 1: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] - - Technique 2: [SCAMPER letter + method] - - Application: [How applied] - - New ideas: - - [Idea] -[Repeat for 3 branches] - - - -- Bias: [Name] - - Evidence in ideas: [How it appears] - - Countermeasure: [Concrete action] -[At least 1 bias] - - - -1. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -2. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] -3. [Idea title] - - Description (2-3 sentences): [Abstract description] - - Why innovative/non-obvious: [Rationale] - - Topic fit (abstract): [How it addresses topic] - - - -[Brief recap of process and why final ideas are stronger after SCAMPER and bias checks] - - - - -FAILURE -- Root tag `` or any required sub-tag is missing, malformed, or incomplete. -- `free_association` has fewer than 8 or more than 10 items. -- `mind_map` has fewer than 3 main branches or insufficient sub-branches. -- `scamper` does not cover 3 branches with 2 techniques each. -- `top_ideas` does not contain exactly 3 ideas. -- Top ideas include banned specific-technology terms (`AI`, `blockchain`, `VR`). -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/innovative-product-ideas-from-structured-brainstorming/agents/openai.yaml b/skills/innovative-product-ideas-from-structured-brainstorming/agents/openai.yaml deleted file mode 100644 index d6b2a20d..00000000 --- a/skills/innovative-product-ideas-from-structured-brainstorming/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Innovative product ideas from structured brainstorming" - short_description: "Innovative product ideas from structured brainstorming. Use when the user needs a product workflow for ideation &..." - brand_color: "#0D9488" - default_prompt: "Use $innovative-product-ideas-from-structured-brainstorming with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/innovative-product-ideas-from-structured-brainstorming/productize.json b/skills/innovative-product-ideas-from-structured-brainstorming/productize.json deleted file mode 100644 index c1339a84..00000000 --- a/skills/innovative-product-ideas-from-structured-brainstorming/productize.json +++ /dev/null @@ -1,40 +0,0 @@ -{ - "title": "Innovative product ideas from structured brainstorming", - "category": "Discovery", - "lifecycle": "Think", - "tags": [ - "innovative-product-ideas-from-structured-brainstorming", - "innovative", - "ideas", - "structured", - "brainstorming", - "ideation", - "creativity", - "discovery" - ], - "use_when": "Innovative product ideas from structured brainstorming. Use when the user needs a product workflow for ideation & creativity related to innovative product ideas from structured brainstorming. Trigger terms: brainstorming, product-ideas, structured-ideation, creativity, product-management.", - "do_not_use_when": "Do not use Innovative product ideas from structured brainstorming when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action", - "routing_signals": [ - "innovative-product-ideas-from-structured-brainstorming", - "innovative", - "ideas", - "structured", - "brainstorming", - "ideation", - "creativity", - "discovery" - ], - "framework_fit": "Innovative product ideas from structured brainstorming fits Discovery work in the Think lifecycle when the user needs Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Innovative product ideas from structured brainstorming as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Innovative product ideas from structured brainstorming when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $innovative-product-ideas-from-structured-brainstorming to turn this innovative context into a decision-ready Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action.", - "expected_artifact": "Innovative product ideas from structured brainstorming product artifact with evidence, risks, recommendation, and next action" - } - ] -} diff --git a/skills/interactive-intake-for-ost-inputs/SKILL.md b/skills/interactive-intake-for-ost-inputs/SKILL.md deleted file mode 100644 index 595f7d63..00000000 --- a/skills/interactive-intake-for-ost-inputs/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: interactive-intake-for-ost-inputs -description: >- - Interactive intake for OST inputs. Use when the user needs a product workflow for user - research related to interactive intake for ost inputs. Trigger terms: user-research, ost, - continuous-discovery. ---- - - - -# Interactive intake for OST inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `interactive-intake-for-ost-inputs` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Interactive intake for OST inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Interactive intake for OST inputs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Act as an intake orchestrator for downstream OST inputs. -- Parse existing user-provided context first, then ask only missing critical questions. -- Collect and normalize exactly four variables: -- `{{business_outcome}}`: one concise, outcome-focused sentence (no solution wording). -- `{{journey_nodes_as_list}}`: JSON array of distinct journey moments (not features). -- `{{interview_transcripts_or_story_snippets}}`: markdown snippets with attribution and timestamps when available. -- `{{constraints_or_principles}}`: short markdown list/sentence or `None stated`. -- Apply quality guards: -- Reframe solution-flavored outcomes into measurable outcomes. -- Rephrase feature-like nodes into moments in time. -- Add minimal attribution labels when transcript context is sparse. -- Stop only when all four fields are present, clear, distinct, normalized, and confirmed. - -FORMAT -Return exactly this structure: - -{{business_outcome}}: [one concise, outcome-focused sentence] - -{{journey_nodes_as_list}}: ["[Moment 1]", "[Moment 2]", "[Moment 3]"] - -{{interview_transcripts_or_story_snippets}}: -[markdown transcript/snippets with speaker labels and timestamps if available] - -{{constraints_or_principles}}: -[short markdown list or sentence; if none provided, write "None stated"] - -FAILURE -- Any of the four required variables is missing or malformed. -- `{{business_outcome}}` is solution-flavored or not measurable/outcome-oriented. -- `{{journey_nodes_as_list}}` is not valid JSON array syntax or contains features instead of moments. -- Interview material lacks usable attribution/context when source data allows it. -- Constraints field is omitted instead of explicitly set to `None stated`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/interactive-intake-for-ost-inputs/SKILL.md.tmpl b/skills/interactive-intake-for-ost-inputs/SKILL.md.tmpl deleted file mode 100644 index 3c1af499..00000000 --- a/skills/interactive-intake-for-ost-inputs/SKILL.md.tmpl +++ /dev/null @@ -1,73 +0,0 @@ ---- -name: interactive-intake-for-ost-inputs -description: >- - Interactive intake for OST inputs. Use when the user needs a product workflow for user - research related to interactive intake for ost inputs. Trigger terms: user-research, ost, - continuous-discovery. ---- -# Interactive intake for OST inputs - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Interactive intake for OST inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Interactive intake for OST inputs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Act as an intake orchestrator for downstream OST inputs. -- Parse existing user-provided context first, then ask only missing critical questions. -- Collect and normalize exactly four variables: -- `{{business_outcome}}`: one concise, outcome-focused sentence (no solution wording). -- `{{journey_nodes_as_list}}`: JSON array of distinct journey moments (not features). -- `{{interview_transcripts_or_story_snippets}}`: markdown snippets with attribution and timestamps when available. -- `{{constraints_or_principles}}`: short markdown list/sentence or `None stated`. -- Apply quality guards: -- Reframe solution-flavored outcomes into measurable outcomes. -- Rephrase feature-like nodes into moments in time. -- Add minimal attribution labels when transcript context is sparse. -- Stop only when all four fields are present, clear, distinct, normalized, and confirmed. - -FORMAT -Return exactly this structure: - -{{business_outcome}}: [one concise, outcome-focused sentence] - -{{journey_nodes_as_list}}: ["[Moment 1]", "[Moment 2]", "[Moment 3]"] - -{{interview_transcripts_or_story_snippets}}: -[markdown transcript/snippets with speaker labels and timestamps if available] - -{{constraints_or_principles}}: -[short markdown list or sentence; if none provided, write "None stated"] - -FAILURE -- Any of the four required variables is missing or malformed. -- `{{business_outcome}}` is solution-flavored or not measurable/outcome-oriented. -- `{{journey_nodes_as_list}}` is not valid JSON array syntax or contains features instead of moments. -- Interview material lacks usable attribution/context when source data allows it. -- Constraints field is omitted instead of explicitly set to `None stated`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/interactive-intake-for-ost-inputs/agents/openai.yaml b/skills/interactive-intake-for-ost-inputs/agents/openai.yaml deleted file mode 100644 index 69be8403..00000000 --- a/skills/interactive-intake-for-ost-inputs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Interactive intake for OST inputs" - short_description: "Interactive intake for OST inputs. Use when the user needs a product workflow for user research related to..." - brand_color: "#0D9488" - default_prompt: "Use $interactive-intake-for-ost-inputs with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/interactive-intake-for-ost-inputs/productize.json b/skills/interactive-intake-for-ost-inputs/productize.json deleted file mode 100644 index d8e055dc..00000000 --- a/skills/interactive-intake-for-ost-inputs/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Interactive intake for OST inputs", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "interactive-intake-for-ost-inputs", - "interactive", - "intake", - "ost", - "inputs", - "research", - "discovery" - ], - "use_when": "Interactive intake for OST inputs. Use when the user needs a product workflow for user research related to interactive intake for ost inputs. Trigger terms: user-research, ost, continuous-discovery.", - "do_not_use_when": "Do not use Interactive intake for OST inputs when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "interactive-intake-for-ost-inputs", - "interactive", - "intake", - "ost", - "inputs", - "research", - "discovery" - ], - "framework_fit": "Interactive intake for OST inputs fits Discovery work in the Discover lifecycle when the user needs Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Interactive intake for OST inputs as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Interactive intake for OST inputs when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $interactive-intake-for-ost-inputs to turn this interactive context into a decision-ready Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Interactive intake for OST inputs research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/lean-canvas/SKILL.md b/skills/lean-canvas/SKILL.md deleted file mode 100644 index 4183465d..00000000 --- a/skills/lean-canvas/SKILL.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -name: lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- - - - -# Lean Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `lean-canvas` -- **Lifecycle**: Think -- **Category**: Business Model -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/lean-canvas/SKILL.md.tmpl b/skills/lean-canvas/SKILL.md.tmpl deleted file mode 100644 index c58b01f6..00000000 --- a/skills/lean-canvas/SKILL.md.tmpl +++ /dev/null @@ -1,143 +0,0 @@ ---- -name: lean-canvas -description: >- - Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas - with hypotheses and validation priorities. ---- -# Lean Canvas - -{{PRODUCTIZE_PREAMBLE}} - -Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities -- **Source method**: pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: lean-canvas -- **Description**: Generate a Lean Canvas business model with detailed sections for problem, solution, metrics, cost structure, UVP, unfair advantage, channels, segments, and revenue. -- **Triggers**: lean canvas, startup canvas, lean model, business hypothesis - -## Instructions - -You are a business model strategist designing a Lean Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Lean Canvas that outlines the business hypothesis and key business model assumptions for the product. - -## Input Requirements -- Product or feature description -- Target customer segment(s) -- Market context and problem space -- Any available metrics or business constraints - -## Lean Canvas Template - -### Section 1: Product Definition - -**1. Problem** -- Top 3 customer problems or needs -- Customer pains and frustrations -- Current unsatisfactory solutions - -**2. Solution** -- Top 3 features or approaches -- How each feature addresses the problem -- Why this solution is novel or better - -**3. Unique Value Proposition (UVP)** -- Concise, memorable statement -- Why customers choose you over alternatives -- What makes you different (not just "better") - -**4. Unfair Advantage** -- What defensibility exists? -- Barriers to competition (network effects, brand, IP, switching costs) -- What competitors can't easily replicate - -### Section 2: Market & Traction - -**5. Customer Segments** -- Who is the target customer? -- Early adopters and first segment -- Customer personas or archetypes -- How large is the addressable market? - -**6. Channels** -- How do you reach customers? -- Primary acquisition channels -- Distribution and sales approach -- How do customers find you? - -**7. Revenue Streams** -- How do you make money? -- Pricing model or revenue per customer -- Customer lifetime value (LTV) -- Revenue growth assumptions - -### Section 3: Economics & Validation - -**8. Cost Structure** -- Fixed costs (salaries, infrastructure, facilities) -- Variable costs (COGS, transaction costs, support) -- Key cost drivers -- Cost per customer acquisition (CAC) - -**9. Key Metrics** -- Activation: How do users get value quickly? -- Retention: How many users stick around? -- Revenue: How do we measure financial success? -- North Star metric for the business - -## Output Process -1. Define the core problem(s) being solved -2. Outline 2-3 solution approaches -3. Craft a compelling UVP -4. Identify what creates competitive advantage -5. Target 1-2 customer segments -6. Map acquisition channels -7. Define revenue model and pricing -8. Estimate cost structure -9. Identify 3-5 critical metrics to track -10. Surface key assumptions and hypotheses -11. Suggest validation experiments (landing page, interviews, MVP) - -### Domain Context - -**Lean Canvas vs Business Model Canvas vs Startup Canvas**: - -Lean Canvas (Ash Maurya) is a startup-focused adaptation of the Business Model Canvas that replaces Partners/Activities/Resources with Problem/Solution/Unfair Advantage. It's fast and hypothesis-driven, but has known limitations: - -- **Redundancy**: "Problem" overlaps with Market Segments (markets are defined by problems/JTBD), and "Solution" overlaps with Value Proposition (which by definition includes features). This can create confusion about what goes where. -- **Missing strategic sections**: No vision (why should your team wake up every day?), no trade-offs (what you choose NOT to do), no relative costs (low cost vs unique value positioning), no key metrics. -- **Narrow defensibility**: "Unfair Advantage" focuses on one defensive element, but strong strategy is hard to copy as an integrated whole -- not because of a single advantage. -- **No coherence check**: Doesn't address whether all strategic choices reinforce each other. - -**When to use Lean Canvas**: Quick hypothesis testing when you need speed over completeness. Best as a brainstorming tool, not a strategy document. - -**Consider instead**: **Startup Canvas** (Pawe Huryn) separates strategy (9 sections from the Product Strategy Canvas) from business model (Cost Structure + Revenue Streams). Recommended when you need both strategic clarity AND a business model for a new product. - -## Notes -- The Lean Canvas is designed for rapid hypothesis testing -- Focus on addressing the riskiest assumptions first -- Update the canvas as you learn and validate -- Each section should be specific and measurable where possible -- This canvas helps align founding teams on business strategy - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/lean-canvas/agents/openai.yaml b/skills/lean-canvas/agents/openai.yaml deleted file mode 100644 index 8cf576aa..00000000 --- a/skills/lean-canvas/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Lean Canvas" - short_description: "Lean Canvas. Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and..." - brand_color: "#9333EA" - default_prompt: "Use $lean-canvas with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/lean-canvas/productize.json b/skills/lean-canvas/productize.json deleted file mode 100644 index 28e01002..00000000 --- a/skills/lean-canvas/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Lean Canvas", - "category": "Business Model", - "lifecycle": "Think", - "tags": [ - "lean-canvas", - "startup", - "problem-solution", - "uvp", - "riskiest-assumptions", - "strategize", - "lean", - "canvas", - "business", - "model", - "innovation", - "use", - "turning" - ], - "use_when": "Use when turning a startup idea or early product concept into a Lean Canvas with hypotheses and validation priorities.", - "do_not_use_when": "Do not use Lean Canvas when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities", - "routing_signals": [ - "lean-canvas", - "startup", - "problem-solution", - "uvp", - "riskiest-assumptions", - "when", - "turning", - "idea", - "early", - "product", - "concept", - "into", - "lean", - "canvas" - ], - "framework_fit": "Best for 0-to-1 products where problem, segment, unfair advantage, channels, and revenue are still assumptions.", - "failure_modes": [ - "Produces Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Lean Canvas as generic Business Model advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Lean Canvas when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $lean-canvas to turn this startup context into a decision-ready Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities.", - "expected_artifact": "Lean Canvas with problem, solution, UVP, metrics, channels, revenue, costs, and risk priorities" - } - ], - "imported_from": "pm-skills-main/pm-product-strategy/skills/lean-canvas/SKILL.md" -} diff --git a/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md b/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md deleted file mode 100644 index 79e8327c..00000000 --- a/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: limit-based-product-strategy-from-problem-to-execution-plan -description: >- - Limit-based product strategy from problem to execution plan. Use when the user needs a - product workflow for product strategy related to limit-based product strategy from problem - to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, - structured-thinking. ---- - - - -# Limit-based product strategy from problem to execution plan - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `limit-based-product-strategy-from-problem-to-execution-plan` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Limit-based product strategy from problem to execution plan**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Produce a high-quality deliverable for: Limit-based product strategy from problem to execution plan. -Success metric: -- Applies the full Limit-Based Product Thinking framework end-to-end. -- Produces concrete milestones, levers, assumptions, and a phased execution plan. -- Keeps outputs grounded in the provided problem statement. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM_STATEMENT}}`; if critical details are missing, state assumptions explicitly. -- Follow all 7 framework steps in order. -- Provide quantified convergence milestones at 10%, 25%, 50%, 75%, 90% with dates or triggers. -- Identify levers to accelerate convergence and explicitly name the top 1โ€“2 highest impact moves. -- List critical assumptions with validation methods. -- Provide a 3-phase plan (Foundation, Acceleration, Optimization) with timelines and resource guidance. - -FORMAT -Return exactly this structure: - - -1. Growth Variable: [Your identified variable] - -2. Limit State Description: - [Your vivid description of the fully mature state] - -3. Core Properties of the Limit: - [List of key features and interactions] - -4. Convergence Estimate: - [Growth curve and milestones] - -5. Acceleration Strategies: - [Prioritized list of levers to steepen the curve] - -6. Critical Assumptions: - [List of assumptions with validation methods] - -7. Product Vision and Execution: - Vision Statement: [One-sentence summary] - Roadmap: [Major milestones and timelines] - 3-Phase Plan: [Brief outline of each phase] - Resource Allocation: [Key recommendations] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Convergence milestones are missing required percentages or triggers/dates. -- Acceleration strategies lack prioritized top 1โ€“2 levers. -- Assumptions lack validation methods. -- 3-phase plan is missing or not sequenced. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md.tmpl b/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md.tmpl deleted file mode 100644 index 44e0eff2..00000000 --- a/skills/limit-based-product-strategy-from-problem-to-execution-plan/SKILL.md.tmpl +++ /dev/null @@ -1,82 +0,0 @@ ---- -name: limit-based-product-strategy-from-problem-to-execution-plan -description: >- - Limit-based product strategy from problem to execution plan. Use when the user needs a - product workflow for product strategy related to limit-based product strategy from problem - to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, - structured-thinking. ---- -# Limit-based product strategy from problem to execution plan - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Limit-based product strategy from problem to execution plan**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} - - -GOAL -Produce a high-quality deliverable for: Limit-based product strategy from problem to execution plan. -Success metric: -- Applies the full Limit-Based Product Thinking framework end-to-end. -- Produces concrete milestones, levers, assumptions, and a phased execution plan. -- Keeps outputs grounded in the provided problem statement. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PROBLEM_STATEMENT}}`; if critical details are missing, state assumptions explicitly. -- Follow all 7 framework steps in order. -- Provide quantified convergence milestones at 10%, 25%, 50%, 75%, 90% with dates or triggers. -- Identify levers to accelerate convergence and explicitly name the top 1โ€“2 highest impact moves. -- List critical assumptions with validation methods. -- Provide a 3-phase plan (Foundation, Acceleration, Optimization) with timelines and resource guidance. - -FORMAT -Return exactly this structure: - - -1. Growth Variable: [Your identified variable] - -2. Limit State Description: - [Your vivid description of the fully mature state] - -3. Core Properties of the Limit: - [List of key features and interactions] - -4. Convergence Estimate: - [Growth curve and milestones] - -5. Acceleration Strategies: - [Prioritized list of levers to steepen the curve] - -6. Critical Assumptions: - [List of assumptions with validation methods] - -7. Product Vision and Execution: - Vision Statement: [One-sentence summary] - Roadmap: [Major milestones and timelines] - 3-Phase Plan: [Brief outline of each phase] - Resource Allocation: [Key recommendations] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Convergence milestones are missing required percentages or triggers/dates. -- Acceleration strategies lack prioritized top 1โ€“2 levers. -- Assumptions lack validation methods. -- 3-phase plan is missing or not sequenced. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/limit-based-product-strategy-from-problem-to-execution-plan/agents/openai.yaml b/skills/limit-based-product-strategy-from-problem-to-execution-plan/agents/openai.yaml deleted file mode 100644 index 91811d66..00000000 --- a/skills/limit-based-product-strategy-from-problem-to-execution-plan/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Limit-based product strategy from problem to execution plan" - short_description: "Limit-based product strategy from problem to execution plan. Use when the user needs a product workflow for product..." - brand_color: "#059669" - default_prompt: "Use $limit-based-product-strategy-from-problem-to-execution-plan with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/limit-based-product-strategy-from-problem-to-execution-plan/productize.json b/skills/limit-based-product-strategy-from-problem-to-execution-plan/productize.json deleted file mode 100644 index e07fb286..00000000 --- a/skills/limit-based-product-strategy-from-problem-to-execution-plan/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Limit-based product strategy from problem to execution plan", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "limit-based-product-strategy-from-problem-to-execution-plan", - "limit", - "problem", - "execution", - "plan" - ], - "use_when": "Limit-based product strategy from problem to execution plan. Use when the user needs a product workflow for product strategy related to limit-based product strategy from problem to execution plan. Trigger terms: product-strategy, roadmapping, long-term-thinking, structured-thinking.", - "do_not_use_when": "Do not use Limit-based product strategy from problem to execution plan when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "limit-based-product-strategy-from-problem-to-execution-plan", - "limit", - "problem", - "execution", - "plan" - ], - "framework_fit": "Limit-based product strategy from problem to execution plan fits Strategy work in the Strategize lifecycle when the user needs Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Limit-based product strategy from problem to execution plan as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Limit-based product strategy from problem to execution plan when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $limit-based-product-strategy-from-problem-to-execution-plan to turn this limit context into a decision-ready Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Limit-based product strategy from problem to execution plan strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/low-frequency-to-power-user-transition-strategy/SKILL.md b/skills/low-frequency-to-power-user-transition-strategy/SKILL.md deleted file mode 100644 index 22037568..00000000 --- a/skills/low-frequency-to-power-user-transition-strategy/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: low-frequency-to-power-user-transition-strategy -description: >- - Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow - for product strategy related to low-frequency-to-power-user transition strategy. Trigger - terms: product-strategy, engagement, activation, retention. ---- - - - -# Low-Frequency-to-Power-User Transition Strategy - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `low-frequency-to-power-user-transition-strategy` -- **Lifecycle**: Growth -- **Category**: Growth -- **Primary artifact**: Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks - -Use this skill to run the Productize prompt contract for **Low-Frequency-to-Power-User Transition Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_DESCRIPTION}} -- {{CURRENT_USE_CASE}} -- {{TARGET_USE_CASE}} - - -GOAL -Produce a high-quality deliverable for: Low-Frequency-to-Power-User Transition Strategy. -Success metric: -- Produces a concrete transition plan from low-frequency to high-frequency usage. -- Aligns strategy to current and target use cases with explicit behavioral gaps. -- Includes metrics, timeline, and rollout/education plans grounded in the inputs. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_DESCRIPTION}}`, `{{CURRENT_USE_CASE}}`, and `{{TARGET_USE_CASE}}`; if information is missing, state assumptions explicitly. -- Identify the behavioral gap between current and target usage. -- Provide step-by-step transition plan, education/onboarding, and communication strategy. -- Include rollout plan, key metrics, and timeline for measurement. -- Keep recommendations specific and grounded in the provided context. - -FORMAT -Return exactly this structure: - - -1. Current Use Case Analysis: - [Provide a brief analysis of the current low-frequency use case] - -2. Target Use Case Analysis: - [Provide a brief analysis of the target high-frequency use case] - -3. User Behavior and Needs: - [Summarize key insights about user behavior and needs] - -4. Transition Strategy: - a. Feature Introduction Plan: - [Outline the step-by-step plan for introducing new features] - b. User Education and Onboarding: - [Describe the approach for educating users about the new use case] - c. Communication Strategy: - [Outline the key messages and channels for communicating the benefits] - d. Gradual Rollout Plan: - [Describe the approach for gradually introducing new functionality] - -5. Implementation and Measurement: - a. Key Metrics: - [List the primary metrics to track for measuring success] - b. Timeline: - [Provide a high-level timeline for implementation and evaluation] - c. Feedback and Iteration: - [Describe the plan for collecting user feedback and making improvements] - -6. Potential Challenges and Mitigation Strategies: - [Identify potential obstacles and propose solutions] - -7. Conclusion: - [Summarize the key points of the transition strategy and its potential impact] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Behavioral gap or barriers are not explicitly identified. -- Metrics or timeline are missing. -- Strategies are generic or not tied to the given use cases. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/low-frequency-to-power-user-transition-strategy/SKILL.md.tmpl b/skills/low-frequency-to-power-user-transition-strategy/SKILL.md.tmpl deleted file mode 100644 index 5f5d2436..00000000 --- a/skills/low-frequency-to-power-user-transition-strategy/SKILL.md.tmpl +++ /dev/null @@ -1,90 +0,0 @@ ---- -name: low-frequency-to-power-user-transition-strategy -description: >- - Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow - for product strategy related to low-frequency-to-power-user transition strategy. Trigger - terms: product-strategy, engagement, activation, retention. ---- -# Low-Frequency-to-Power-User Transition Strategy - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Low-Frequency-to-Power-User Transition Strategy**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_DESCRIPTION}} -- {{CURRENT_USE_CASE}} -- {{TARGET_USE_CASE}} - - -GOAL -Produce a high-quality deliverable for: Low-Frequency-to-Power-User Transition Strategy. -Success metric: -- Produces a concrete transition plan from low-frequency to high-frequency usage. -- Aligns strategy to current and target use cases with explicit behavioral gaps. -- Includes metrics, timeline, and rollout/education plans grounded in the inputs. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_DESCRIPTION}}`, `{{CURRENT_USE_CASE}}`, and `{{TARGET_USE_CASE}}`; if information is missing, state assumptions explicitly. -- Identify the behavioral gap between current and target usage. -- Provide step-by-step transition plan, education/onboarding, and communication strategy. -- Include rollout plan, key metrics, and timeline for measurement. -- Keep recommendations specific and grounded in the provided context. - -FORMAT -Return exactly this structure: - - -1. Current Use Case Analysis: - [Provide a brief analysis of the current low-frequency use case] - -2. Target Use Case Analysis: - [Provide a brief analysis of the target high-frequency use case] - -3. User Behavior and Needs: - [Summarize key insights about user behavior and needs] - -4. Transition Strategy: - a. Feature Introduction Plan: - [Outline the step-by-step plan for introducing new features] - b. User Education and Onboarding: - [Describe the approach for educating users about the new use case] - c. Communication Strategy: - [Outline the key messages and channels for communicating the benefits] - d. Gradual Rollout Plan: - [Describe the approach for gradually introducing new functionality] - -5. Implementation and Measurement: - a. Key Metrics: - [List the primary metrics to track for measuring success] - b. Timeline: - [Provide a high-level timeline for implementation and evaluation] - c. Feedback and Iteration: - [Describe the plan for collecting user feedback and making improvements] - -6. Potential Challenges and Mitigation Strategies: - [Identify potential obstacles and propose solutions] - -7. Conclusion: - [Summarize the key points of the transition strategy and its potential impact] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Behavioral gap or barriers are not explicitly identified. -- Metrics or timeline are missing. -- Strategies are generic or not tied to the given use cases. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/low-frequency-to-power-user-transition-strategy/agents/openai.yaml b/skills/low-frequency-to-power-user-transition-strategy/agents/openai.yaml deleted file mode 100644 index 34977bed..00000000 --- a/skills/low-frequency-to-power-user-transition-strategy/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Low-Frequency-to-Power-User Transition Strategy" - short_description: "Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow for product strategy..." - brand_color: "#C2410C" - default_prompt: "Use $low-frequency-to-power-user-transition-strategy with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/low-frequency-to-power-user-transition-strategy/productize.json b/skills/low-frequency-to-power-user-transition-strategy/productize.json deleted file mode 100644 index 1424b2ad..00000000 --- a/skills/low-frequency-to-power-user-transition-strategy/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Low-Frequency-to-Power-User Transition Strategy", - "category": "Growth", - "lifecycle": "Growth", - "tags": [ - "low-frequency-to-power-user-transition-strategy", - "low", - "frequency", - "power", - "transition", - "growth" - ], - "use_when": "Low-Frequency-to-Power-User Transition Strategy. Use when the user needs a product workflow for product strategy related to low-frequency-to-power-user transition strategy. Trigger terms: product-strategy, engagement, activation, retention.", - "do_not_use_when": "Do not use Low-Frequency-to-Power-User Transition Strategy when the request is mainly generic marketing copy, product discovery, or finance valuation; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks", - "routing_signals": [ - "low-frequency-to-power-user-transition-strategy", - "low", - "frequency", - "power", - "transition", - "growth" - ], - "framework_fit": "Appropriate when the user needs to increase engagement depth, repeat usage, activation, retention, or habit formation among low-frequency users.", - "failure_modes": [ - "Produces Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks without tying recommendations to the user's Growth stage, evidence, and decision pressure.", - "Treats Low-Frequency-to-Power-User Transition Strategy as generic Growth advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Low-Frequency-to-Power-User Transition Strategy when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $low-frequency-to-power-user-transition-strategy to turn this low context into a decision-ready Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks.", - "expected_artifact": "Low-Frequency-to-Power-User Transition Strategy growth playbook with bottleneck, segment, experiments, triggers, and sustainability checks" - } - ] -} diff --git a/skills/managerial-finance-dcf/SKILL.md b/skills/managerial-finance-dcf/SKILL.md deleted file mode 100644 index 974b69dd..00000000 --- a/skills/managerial-finance-dcf/SKILL.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -name: managerial-finance-dcf -description: >- - Productize Finance engine for time value of money, DCF, NPV, IRR, payback, - free cash flow, terminal value, project valuation, mutually exclusive investments, - and whether growth creates or destroys value. ---- - - - -# Managerial Finance DCF - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `managerial-finance-dcf` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings - -## Purpose - -Core investment-decision skill for evaluating projects and cash-flow streams. -Use it when comparing investments, building free cash flow forecasts, calculating -NPV/IRR/payback, estimating terminal value, or judging whether growth creates value. - -## Core Formulas - -- `FV_t = C_0 * (1 + r)^t` -- `PV = C_t / (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(C_t / (1 + r)^t)` -- `NPV with TV = -I_0 + sum(FCF_t / (1 + r)^t) + TV_N / (1 + r)^N` -- `0 = -I_0 + sum(C_t / (1 + IRR)^t)` -- `Profitability Index = PV of Future Cash Flows / Initial Investment` -- `FCF = EBIT * (1 - T_c) + Depreciation - CapEx - Delta NWC` -- `NOPAT = EBIT * (1 - T_c)` -- `TV_N = FCF_{N+1} / (r - g)` with `r > g` -- `ROIC = NOPAT / Invested Capital` -- `Reinvestment Rate = (CapEx - Depreciation + Delta NWC) / NOPAT` -- `g = ROIC * Reinvestment Rate` - -## Decision Rules - -- Independent projects: accept if `NPV > 0`; reject if `NPV < 0`. -- Mutually exclusive projects: choose the highest NPV. -- IRR supports the decision, but warn when cash flows change sign more than once, - projects differ in scale or timing, or multiple/no real IRRs exist. -- Growth creates value only when `ROIC > WACC`; it destroys value when `ROIC < WACC`. - -## Required Functions - -Use `$finance-modeling-kernel` functions for PV/FV, streams, NPV, IRR, payback, -discounted payback, annuities, perpetuities, free cash flow, terminal value, -ROIC, reinvestment rate, and sustainable growth. - -## Required Validation - -- Warn if comparing undiscounted cash flows across time. -- Warn if terminal growth exceeds long-run economic growth. -- Reject `g >= r` in growing perpetuity. -- Warn if IRR conflicts with NPV. -- Warn if payback is used as the final decision rule. -- Warn if sunk costs, financing cash flows, non-incremental overhead, cannibalization, - or opportunity cost are mishandled. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Make NPV the primary investment decision rule. diff --git a/skills/managerial-finance-dcf/SKILL.md.tmpl b/skills/managerial-finance-dcf/SKILL.md.tmpl deleted file mode 100644 index 706183a8..00000000 --- a/skills/managerial-finance-dcf/SKILL.md.tmpl +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: managerial-finance-dcf -description: >- - Productize Finance engine for time value of money, DCF, NPV, IRR, payback, - free cash flow, terminal value, project valuation, mutually exclusive investments, - and whether growth creates or destroys value. ---- - -# Managerial Finance DCF - -{{PRODUCTIZE_PREAMBLE}} - -## Purpose - -Core investment-decision skill for evaluating projects and cash-flow streams. -Use it when comparing investments, building free cash flow forecasts, calculating -NPV/IRR/payback, estimating terminal value, or judging whether growth creates value. - -## Core Formulas - -- `FV_t = C_0 * (1 + r)^t` -- `PV = C_t / (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(C_t / (1 + r)^t)` -- `NPV with TV = -I_0 + sum(FCF_t / (1 + r)^t) + TV_N / (1 + r)^N` -- `0 = -I_0 + sum(C_t / (1 + IRR)^t)` -- `Profitability Index = PV of Future Cash Flows / Initial Investment` -- `FCF = EBIT * (1 - T_c) + Depreciation - CapEx - Delta NWC` -- `NOPAT = EBIT * (1 - T_c)` -- `TV_N = FCF_{N+1} / (r - g)` with `r > g` -- `ROIC = NOPAT / Invested Capital` -- `Reinvestment Rate = (CapEx - Depreciation + Delta NWC) / NOPAT` -- `g = ROIC * Reinvestment Rate` - -## Decision Rules - -- Independent projects: accept if `NPV > 0`; reject if `NPV < 0`. -- Mutually exclusive projects: choose the highest NPV. -- IRR supports the decision, but warn when cash flows change sign more than once, - projects differ in scale or timing, or multiple/no real IRRs exist. -- Growth creates value only when `ROIC > WACC`; it destroys value when `ROIC < WACC`. - -## Required Functions - -Use `$finance-modeling-kernel` functions for PV/FV, streams, NPV, IRR, payback, -discounted payback, annuities, perpetuities, free cash flow, terminal value, -ROIC, reinvestment rate, and sustainable growth. - -## Required Validation - -- Warn if comparing undiscounted cash flows across time. -- Warn if terminal growth exceeds long-run economic growth. -- Reject `g >= r` in growing perpetuity. -- Warn if IRR conflicts with NPV. -- Warn if payback is used as the final decision rule. -- Warn if sunk costs, financing cash flows, non-incremental overhead, cannibalization, - or opportunity cost are mishandled. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. Make NPV the primary investment decision rule. diff --git a/skills/managerial-finance-dcf/agents/openai.yaml b/skills/managerial-finance-dcf/agents/openai.yaml deleted file mode 100644 index ecfabe0f..00000000 --- a/skills/managerial-finance-dcf/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Managerial Finance DCF" - short_description: "Productize Finance engine for time value of money, DCF, NPV, IRR, payback, free cash flow, terminal value, project..." - brand_color: "#0369A1" - default_prompt: "Use $managerial-finance-dcf with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/managerial-finance-dcf/productize.json b/skills/managerial-finance-dcf/productize.json deleted file mode 100644 index 361a604f..00000000 --- a/skills/managerial-finance-dcf/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Managerial Finance DCF", - "category": "Finance", - "lifecycle": "Measure", - "tags": [ - "managerial-finance-dcf", - "dcf", - "npv", - "irr", - "payback", - "free-cash-flow", - "terminal-value", - "roic", - "investment-decision", - "project-valuation", - "managerial", - "finance", - "productize", - "engine" - ], - "use_when": "Use when evaluating a project, comparing mutually exclusive investments, calculating NPV, IRR, payback, DCF, free cash flow, terminal value, or whether growth creates value.", - "do_not_use_when": "Do not use when the user primarily needs a full company valuation, VC term-sheet analysis, WACC estimation, or public-market comparables without project cash-flow analysis.", - "output_artifact": "DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings", - "routing_signals": [ - "project-npv", - "investment-decision", - "dcf", - "irr", - "payback", - "free-cash-flow", - "terminal-value", - "growing-perpetuity", - "roic", - "growth-creates-value", - "managerial-finance-dcf", - "managerial", - "finance", - "productize" - ], - "framework_fit": "Best for operating cash-flow forecasts and project-level value decisions where NPV is the primary rule.", - "failure_modes": [ - "Produces DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings without tying recommendations to the user's Measure stage, evidence, and decision pressure.", - "Treats Managerial Finance DCF as generic Finance advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Managerial Finance DCF when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $managerial-finance-dcf to evaluate this project with initial investment, three years of FCF, terminal value, and discount rate.", - "expected_artifact": "DCF investment-decision analysis with cash-flow timing, NPV, supporting metrics, decision rule, interpretation, and warnings" - } - ] -} diff --git a/skills/map-power-dynamics-before-meetings/SKILL.md b/skills/map-power-dynamics-before-meetings/SKILL.md deleted file mode 100644 index 106cf1e1..00000000 --- a/skills/map-power-dynamics-before-meetings/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: map-power-dynamics-before-meetings -description: >- - Map power dynamics before meetings. Use when the user needs a product workflow for - stakeholder management related to map power dynamics before meetings. Trigger terms: - stakeholders, power-dynamics, meetings, communication. ---- - - - -# Map power dynamics before meetings - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `map-power-dynamics-before-meetings` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Map power dynamics before meetings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DETAILS}} -- {{ATTENDEES_INFO}} - - -GOAL -Produce a high-quality deliverable for: "Map power dynamics before meetings". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{MEETING_DETAILS}}` and `{{ATTENDEES_INFO}}` to map meeting-specific power dynamics. -- Identify formal hierarchy, informal influence signals, alliances/conflicts, and each attendee's stake in outcomes. -- Rank attendees by influence in this meeting context. -- Identify decision-makers, influencers, power imbalances, and likely conflict points. -- Provide actionable strategies to navigate dynamics during the meeting. -- If information is insufficient for any claim, explicitly state the uncertainty. - -FORMAT -Return exactly this structure: - - - -[List attendees in order of influence, with brief notes on their power sources] - - - -[Bullet points of important observations about the power dynamics] - - - -[Bullet points of strategies to navigate the power dynamics effectively] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Influence ranking is not meeting-contextual or lacks power-source rationale. -- Recommendations are generic or not tied to identified dynamics/conflicts. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/map-power-dynamics-before-meetings/SKILL.md.tmpl b/skills/map-power-dynamics-before-meetings/SKILL.md.tmpl deleted file mode 100644 index 85ef0648..00000000 --- a/skills/map-power-dynamics-before-meetings/SKILL.md.tmpl +++ /dev/null @@ -1,70 +0,0 @@ ---- -name: map-power-dynamics-before-meetings -description: >- - Map power dynamics before meetings. Use when the user needs a product workflow for - stakeholder management related to map power dynamics before meetings. Trigger terms: - stakeholders, power-dynamics, meetings, communication. ---- -# Map power dynamics before meetings - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Map power dynamics before meetings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DETAILS}} -- {{ATTENDEES_INFO}} - - -GOAL -Produce a high-quality deliverable for: "Map power dynamics before meetings". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{MEETING_DETAILS}}` and `{{ATTENDEES_INFO}}` to map meeting-specific power dynamics. -- Identify formal hierarchy, informal influence signals, alliances/conflicts, and each attendee's stake in outcomes. -- Rank attendees by influence in this meeting context. -- Identify decision-makers, influencers, power imbalances, and likely conflict points. -- Provide actionable strategies to navigate dynamics during the meeting. -- If information is insufficient for any claim, explicitly state the uncertainty. - -FORMAT -Return exactly this structure: - - - -[List attendees in order of influence, with brief notes on their power sources] - - - -[Bullet points of important observations about the power dynamics] - - - -[Bullet points of strategies to navigate the power dynamics effectively] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Influence ranking is not meeting-contextual or lacks power-source rationale. -- Recommendations are generic or not tied to identified dynamics/conflicts. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/map-power-dynamics-before-meetings/agents/openai.yaml b/skills/map-power-dynamics-before-meetings/agents/openai.yaml deleted file mode 100644 index 3b1d09ca..00000000 --- a/skills/map-power-dynamics-before-meetings/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Map power dynamics before meetings" - short_description: "Map power dynamics before meetings. Use when the user needs a product workflow for stakeholder management related to..." - brand_color: "#0891B2" - default_prompt: "Use $map-power-dynamics-before-meetings with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/map-power-dynamics-before-meetings/productize.json b/skills/map-power-dynamics-before-meetings/productize.json deleted file mode 100644 index 06d7e9a4..00000000 --- a/skills/map-power-dynamics-before-meetings/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Map power dynamics before meetings", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "map-power-dynamics-before-meetings", - "map", - "power", - "dynamics", - "before", - "meetings" - ], - "use_when": "Map power dynamics before meetings. Use when the user needs a product workflow for stakeholder management related to map power dynamics before meetings. Trigger terms: stakeholders, power-dynamics, meetings, communication.", - "do_not_use_when": "Do not use Map power dynamics before meetings when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "map-power-dynamics-before-meetings", - "map", - "power", - "dynamics", - "before", - "meetings" - ], - "framework_fit": "Map power dynamics before meetings fits Stakeholder Communication work in the Align lifecycle when the user needs Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Map power dynamics before meetings as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Map power dynamics before meetings when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $map-power-dynamics-before-meetings to turn this map context into a decision-ready Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Map power dynamics before meetings stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md b/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md deleted file mode 100644 index 05f3aa03..00000000 --- a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: market-opportunities-from-jobs-to-be-done-market-canvas -description: >- - Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product - workflow for product strategy related to market opportunities from jobs-to-be-done market - canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, - product-strategy. ---- - - - -# Market opportunities from Jobs-to-be-Done market canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunities-from-jobs-to-be-done-market-canvas` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path - -Use this skill to run the Productize prompt contract for **Market opportunities from Jobs-to-be-Done market canvas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_OR_SERVICE}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Market opportunities from Jobs-to-be-Done market canvas. -Success metric: -- Guides the user through all 8 JTBD canvas steps with clear prompts. -- Keeps responses tied to provided `{{USER_INPUT}}` and the product context. -- Ends with a concise summary prompt that reflects the completed canvas. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_OR_SERVICE}}` and `{{USER_INPUT}}`; if context is missing, state assumptions explicitly. -- Ask for user input at each of the 8 JTBD canvas steps. -- Provide a brief explanation before each stepโ€™s prompt. -- Require the user to answer within the specified `` tags. -- End by requesting a `` that synthesizes the full canvas. -- Remind the user to use `{{USER_INPUT}}` when answering. - -FORMAT -Return exactly this structure: - - -[Prompt + explanation for Traditional Market Definition] - - - -[Prompt + explanation for Job Executor Determination] - - - -[Prompt + explanation for Abstracted Job Executor] - - - -[Prompt + explanation for Job Executor Documentation] - - - -[Prompt + explanation for Product Function Analysis] - - - -[Prompt + explanation for Complementary Product Analysis] - - - -[Prompt + explanation for Job Statement Abstraction] - - - -[Prompt + explanation for Final Job Documentation] - - - -[Prompt asking the user to summarize the completed canvas] - - -FAILURE -- Any required step tag in `FORMAT` is missing, malformed, or incomplete. -- Prompts do not request user responses within the correct `` tags. -- User is not reminded to use `{{USER_INPUT}}` for responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md.tmpl b/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md.tmpl deleted file mode 100644 index b749c3f3..00000000 --- a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/SKILL.md.tmpl +++ /dev/null @@ -1,91 +0,0 @@ ---- -name: market-opportunities-from-jobs-to-be-done-market-canvas -description: >- - Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product - workflow for product strategy related to market opportunities from jobs-to-be-done market - canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, - product-strategy. ---- -# Market opportunities from Jobs-to-be-Done market canvas - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Market opportunities from Jobs-to-be-Done market canvas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_OR_SERVICE}} -- {{USER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Market opportunities from Jobs-to-be-Done market canvas. -Success metric: -- Guides the user through all 8 JTBD canvas steps with clear prompts. -- Keeps responses tied to provided `{{USER_INPUT}}` and the product context. -- Ends with a concise summary prompt that reflects the completed canvas. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_OR_SERVICE}}` and `{{USER_INPUT}}`; if context is missing, state assumptions explicitly. -- Ask for user input at each of the 8 JTBD canvas steps. -- Provide a brief explanation before each stepโ€™s prompt. -- Require the user to answer within the specified `` tags. -- End by requesting a `` that synthesizes the full canvas. -- Remind the user to use `{{USER_INPUT}}` when answering. - -FORMAT -Return exactly this structure: - - -[Prompt + explanation for Traditional Market Definition] - - - -[Prompt + explanation for Job Executor Determination] - - - -[Prompt + explanation for Abstracted Job Executor] - - - -[Prompt + explanation for Job Executor Documentation] - - - -[Prompt + explanation for Product Function Analysis] - - - -[Prompt + explanation for Complementary Product Analysis] - - - -[Prompt + explanation for Job Statement Abstraction] - - - -[Prompt + explanation for Final Job Documentation] - - - -[Prompt asking the user to summarize the completed canvas] - - -FAILURE -- Any required step tag in `FORMAT` is missing, malformed, or incomplete. -- Prompts do not request user responses within the correct `` tags. -- User is not reminded to use `{{USER_INPUT}}` for responses. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/agents/openai.yaml b/skills/market-opportunities-from-jobs-to-be-done-market-canvas/agents/openai.yaml deleted file mode 100644 index 9545e760..00000000 --- a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market opportunities from Jobs-to-be-Done market canvas" - short_description: "Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product workflow for product..." - brand_color: "#0F766E" - default_prompt: "Use $market-opportunities-from-jobs-to-be-done-market-canvas with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/productize.json b/skills/market-opportunities-from-jobs-to-be-done-market-canvas/productize.json deleted file mode 100644 index 9884653f..00000000 --- a/skills/market-opportunities-from-jobs-to-be-done-market-canvas/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Market opportunities from Jobs-to-be-Done market canvas", - "category": "Venture / 0-1", - "lifecycle": "Strategize", - "tags": [ - "market-opportunities-from-jobs-to-be-done-market-canvas", - "market", - "opportunities", - "jobs", - "done", - "canvas" - ], - "use_when": "Market opportunities from Jobs-to-be-Done market canvas. Use when the user needs a product workflow for product strategy related to market opportunities from jobs-to-be-done market canvas. Trigger terms: jobs-to-be-done, market-definition, customer-insight, product-strategy.", - "do_not_use_when": "Do not use Market opportunities from Jobs-to-be-Done market canvas when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path", - "routing_signals": [ - "market-opportunities-from-jobs-to-be-done-market-canvas", - "market", - "opportunities", - "jobs", - "done", - "canvas" - ], - "framework_fit": "Market opportunities from Jobs-to-be-Done market canvas fits Venture / 0-1 work in the Strategize lifecycle when the user needs Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Market opportunities from Jobs-to-be-Done market canvas as generic Venture / 0-1 advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Market opportunities from Jobs-to-be-Done market canvas when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $market-opportunities-from-jobs-to-be-done-market-canvas to turn this market context into a decision-ready Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path.", - "expected_artifact": "Market opportunities from Jobs-to-be-Done market canvas venture brief with target segment, wedge, assumptions, and validation path" - } - ] -} diff --git a/skills/market-opportunity/SKILL.md b/skills/market-opportunity/SKILL.md deleted file mode 100644 index 23f1cbe0..00000000 --- a/skills/market-opportunity/SKILL.md +++ /dev/null @@ -1,225 +0,0 @@ ---- -name: market-opportunity -description: >- - Identify, compare, and choose market opportunities for a venture, product, technology, - or innovation. Use when a founder, entrepreneur, product team, or innovator is - choosing which market to enter, picking a primary customer segment, evaluating whether - a technology has better use cases, deciding whether to pivot, comparing growth - options, framing a venture for investors, or asking variants of "which market should I - target", "is this the right opportunity", "where should I focus", "should I pivot", - or "what else could this be used for". Produces filled-in opportunity canvases for the - Market Opportunity Set, Attractiveness Map, Focus Portfolio Map, and Focus Strategy. - Default to this skill when the question is where to play rather than how to - play. ---- - - - -# Market Opportunity - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-opportunity` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: Market Opportunity venture brief with target segment, wedge, assumptions, and validation path - -Create the complete four-part market opportunity artifact set for choosing where a -venture, technology, product, or innovation should play. - -Use neutral terms such as `canvas`, `opportunity artifact`, `strategy surface`, or the -artifact names below. - -## Argument Hint - -`` - -## Usage - -```text -/market-opportunity $ARGUMENTS -``` - -## Required Artifacts - -For any complete request, create all four artifacts unless the user explicitly asks for -only one: - -1. **Opportunity Overview Canvas**: the three-part overview with opportunity set, - attractiveness map, and focus portfolio map. -2. **Opportunity Set Builder**: abilities -> applications -> customers -> market - opportunities. -3. **Attractiveness Evaluator**: potential and challenge ratings for each market - opportunity. -4. **Focus Portfolio Planner**: primary market opportunity, backup options, growth - options, and pursue/keep/store decisions. - -Load `references/canonical-canvases.md` before creating blank templates, filled -templates, printable layouts, or tables. It defines the exact fields and structure. - -Load `references/rating-and-decision-rules.md` before rating opportunities, -classifying map zones, or recommending primary, backup, and growth options. - -Load `references/output-formats.md` when the user asks for Markdown, HTML, PDF, -slides, visual canvases, or printable templates. - -## Workflow - -### 1. Establish the Input Mode - -Determine whether the user wants: - -- **Blank canvas set**: empty structured artifacts for a team to fill in. -- **Filled canvas set**: completed artifacts from a venture/product/technology idea. -- **Opportunity review**: critique or improve an existing opportunity set. -- **Strategy decision**: choose the primary opportunity and portfolio options. -- **Printable artifact**: create visual HTML/PDF/slide-ready canvases. - -If context is missing, ask only for the smallest useful missing piece: - -- The venture, product, technology, or core ability. -- Candidate applications. -- Candidate customer groups. -- Existing evidence for demand, market size, economics, implementation, timing, and risks. - -### 2. Generate the Market Opportunity Set - -Identify the venture's core abilities or technological elements first. Describe them -independent of the envisioned product. - -Then generate combinations: - -```text -market opportunity = application + customer segment -``` - -Segment customers precisely. Avoid broad labels like "enterprises" or "consumers" -unless the user has no better information. - -### 3. Evaluate Attractiveness - -For each market opportunity, rate: - -- **Potential** - - Compelling reason to buy. - - Market volume. - - Economic viability. -- **Challenge** - - Implementation obstacles. - - Time to revenue. - - External risks. - -Use the four-level rating scale: - -```text -Low / Mid / High / Super High -``` - -Then place each opportunity on the attractiveness map: - -- **Gold Mine** -- **Quick Win** -- **Moon Shot** -- **Questionable** - -### 4. Design the Focus Portfolio - -Choose one **Primary Market Opportunity** based on attractiveness and strategic fit. - -For other attractive opportunities, assess relatedness to the primary opportunity: - -- **Product relatedness**: shared technological competences, required resources, - and necessary networks. -- **Market relatedness**: shared customer values and benefits, sales channels, and - word-of-mouth paths. - -Classify each option: - -- **Growth Option**: attractive and useful for creating additional value. -- **Backup Option**: attractive and does not share major risks with the primary path. -- **Storage**: documented but not worth active preservation now. - -Make one of three action decisions for each option: - -- Pursue now. -- Keep open. -- Place in storage. - -The final strategy must keep at least one credible backup option and one credible -growth option open unless the available evidence makes that impossible. If impossible, -say what evidence or opportunity generation is missing. - -### 5. Tie Strategy to Execution - -For completed strategy outputs, include implications for: - -- Product and technology modularity. -- IP and defensibility. -- Hiring and capability development. -- Stakeholder and investor alignment. -- Brand and market communication. -- Experiments, assumptions, and learning loops. -- Business Model Canvas, Value Proposition Canvas, and Lean Startup integration when - the user asks for execution planning. - -## Output Rules - -- Preserve the canonical field names and rating scales from the reference files. -- Do not collapse the framework into SWOT, generic market sizing, or a feature - prioritization matrix. -- Be explicit about assumptions and evidence gaps. -- Use tables for editable outputs. -- For visual outputs, use the same four-artifact structure and neutral artifact titles. -- Do not copy long passages from source PDFs. Use the exact operational labels and - schemas, with original wording for explanations and recommendations. diff --git a/skills/market-opportunity/SKILL.md.tmpl b/skills/market-opportunity/SKILL.md.tmpl deleted file mode 100644 index ab8b0c23..00000000 --- a/skills/market-opportunity/SKILL.md.tmpl +++ /dev/null @@ -1,166 +0,0 @@ ---- -name: market-opportunity -description: >- - Identify, compare, and choose market opportunities for a venture, product, technology, - or innovation. Use when a founder, entrepreneur, product team, or innovator is - choosing which market to enter, picking a primary customer segment, evaluating whether - a technology has better use cases, deciding whether to pivot, comparing growth - options, framing a venture for investors, or asking variants of "which market should I - target", "is this the right opportunity", "where should I focus", "should I pivot", - or "what else could this be used for". Produces filled-in opportunity canvases for the - Market Opportunity Set, Attractiveness Map, Focus Portfolio Map, and Focus Strategy. - Default to this skill when the question is where to play rather than how to - play. ---- -# Market Opportunity - -{{PRODUCTIZE_PREAMBLE}} - -Create the complete four-part market opportunity artifact set for choosing where a -venture, technology, product, or innovation should play. - -Use neutral terms such as `canvas`, `opportunity artifact`, `strategy surface`, or the -artifact names below. - -## Argument Hint - -`` - -## Usage - -```text -/market-opportunity $ARGUMENTS -``` - -## Required Artifacts - -For any complete request, create all four artifacts unless the user explicitly asks for -only one: - -1. **Opportunity Overview Canvas**: the three-part overview with opportunity set, - attractiveness map, and focus portfolio map. -2. **Opportunity Set Builder**: abilities -> applications -> customers -> market - opportunities. -3. **Attractiveness Evaluator**: potential and challenge ratings for each market - opportunity. -4. **Focus Portfolio Planner**: primary market opportunity, backup options, growth - options, and pursue/keep/store decisions. - -Load `references/canonical-canvases.md` before creating blank templates, filled -templates, printable layouts, or tables. It defines the exact fields and structure. - -Load `references/rating-and-decision-rules.md` before rating opportunities, -classifying map zones, or recommending primary, backup, and growth options. - -Load `references/output-formats.md` when the user asks for Markdown, HTML, PDF, -slides, visual canvases, or printable templates. - -## Workflow - -### 1. Establish the Input Mode - -Determine whether the user wants: - -- **Blank canvas set**: empty structured artifacts for a team to fill in. -- **Filled canvas set**: completed artifacts from a venture/product/technology idea. -- **Opportunity review**: critique or improve an existing opportunity set. -- **Strategy decision**: choose the primary opportunity and portfolio options. -- **Printable artifact**: create visual HTML/PDF/slide-ready canvases. - -If context is missing, ask only for the smallest useful missing piece: - -- The venture, product, technology, or core ability. -- Candidate applications. -- Candidate customer groups. -- Existing evidence for demand, market size, economics, implementation, timing, and risks. - -### 2. Generate the Market Opportunity Set - -Identify the venture's core abilities or technological elements first. Describe them -independent of the envisioned product. - -Then generate combinations: - -```text -market opportunity = application + customer segment -``` - -Segment customers precisely. Avoid broad labels like "enterprises" or "consumers" -unless the user has no better information. - -### 3. Evaluate Attractiveness - -For each market opportunity, rate: - -- **Potential** - - Compelling reason to buy. - - Market volume. - - Economic viability. -- **Challenge** - - Implementation obstacles. - - Time to revenue. - - External risks. - -Use the four-level rating scale: - -```text -Low / Mid / High / Super High -``` - -Then place each opportunity on the attractiveness map: - -- **Gold Mine** -- **Quick Win** -- **Moon Shot** -- **Questionable** - -### 4. Design the Focus Portfolio - -Choose one **Primary Market Opportunity** based on attractiveness and strategic fit. - -For other attractive opportunities, assess relatedness to the primary opportunity: - -- **Product relatedness**: shared technological competences, required resources, - and necessary networks. -- **Market relatedness**: shared customer values and benefits, sales channels, and - word-of-mouth paths. - -Classify each option: - -- **Growth Option**: attractive and useful for creating additional value. -- **Backup Option**: attractive and does not share major risks with the primary path. -- **Storage**: documented but not worth active preservation now. - -Make one of three action decisions for each option: - -- Pursue now. -- Keep open. -- Place in storage. - -The final strategy must keep at least one credible backup option and one credible -growth option open unless the available evidence makes that impossible. If impossible, -say what evidence or opportunity generation is missing. - -### 5. Tie Strategy to Execution - -For completed strategy outputs, include implications for: - -- Product and technology modularity. -- IP and defensibility. -- Hiring and capability development. -- Stakeholder and investor alignment. -- Brand and market communication. -- Experiments, assumptions, and learning loops. -- Business Model Canvas, Value Proposition Canvas, and Lean Startup integration when - the user asks for execution planning. - -## Output Rules - -- Preserve the canonical field names and rating scales from the reference files. -- Do not collapse the framework into SWOT, generic market sizing, or a feature - prioritization matrix. -- Be explicit about assumptions and evidence gaps. -- Use tables for editable outputs. -- For visual outputs, use the same four-artifact structure and neutral artifact titles. -- Do not copy long passages from source PDFs. Use the exact operational labels and - schemas, with original wording for explanations and recommendations. diff --git a/skills/market-opportunity/agents/openai.yaml b/skills/market-opportunity/agents/openai.yaml deleted file mode 100644 index 8f145be3..00000000 --- a/skills/market-opportunity/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market Opportunity" - short_description: "Identify, compare, and choose market opportunities for a venture, product, technology, or innovation. Use when a..." - brand_color: "#0F766E" - default_prompt: "Use $market-opportunity with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/market-opportunity/productize.json b/skills/market-opportunity/productize.json deleted file mode 100644 index b7074820..00000000 --- a/skills/market-opportunity/productize.json +++ /dev/null @@ -1,51 +0,0 @@ -{ - "title": "Market Opportunity", - "category": "Venture / 0-1", - "tags": [ - "market-opportunity", - "venture-strategy", - "market-focus", - "technology-commercialization", - "startup-strategy", - "opportunity-selection", - "lean-startup", - "market", - "opportunity", - "venture", - "identify", - "compare", - "choose", - "opportunities" - ], - "lifecycle": "Strategize", - "use_when": "Identify, compare, and choose market opportunities for a venture, product, technology, or innovation. Use when a founder, entrepreneur, product team, or innovator is choosing which market to enter, picking a primary customer segment, evaluating whether a technology has better use cases, deciding whether to pivot, comparing growth options, framing a venture for investors, or asking variants of \"which market should I target\", \"is this the right opportunity\", \"where should I focus\", \"should I pivot\", or \"what else could this be used for\". Produces filled-in opportunity canvases for the Market Opportunity Set, Attractiveness Map, Focus Portfolio Map, and Focus Strategy. Default to this skill when the question is where to play rather than how to play.", - "do_not_use_when": "Do not use Market Opportunity when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Market Opportunity venture brief with target segment, wedge, assumptions, and validation path", - "routing_signals": [ - "market-opportunity", - "market", - "opportunity", - "venture", - "identify", - "compare", - "choose", - "opportunities" - ], - "framework_fit": "Market Opportunity fits Venture / 0-1 work in the Strategize lifecycle when the user needs Market Opportunity venture brief with target segment, wedge, assumptions, and validation path and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Market Opportunity venture brief with target segment, wedge, assumptions, and validation path without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Market Opportunity as generic Venture / 0-1 advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Market Opportunity when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $market-opportunity to turn this market context into a decision-ready Market Opportunity venture brief with target segment, wedge, assumptions, and validation path.", - "expected_artifact": "Market Opportunity venture brief with target segment, wedge, assumptions, and validation path" - } - ], - "references": [ - "references/canonical-canvases.md", - "references/output-formats.md", - "references/rating-and-decision-rules.md" - ] -} diff --git a/skills/market-opportunity/references/canonical-canvases.md b/skills/market-opportunity/references/canonical-canvases.md deleted file mode 100644 index a3c436db..00000000 --- a/skills/market-opportunity/references/canonical-canvases.md +++ /dev/null @@ -1,234 +0,0 @@ -# Canonical Market Opportunity Canvases - -Use these four canvases as the canonical output surfaces. Use neutral artifact names in -user-facing output. - -## 1. Opportunity Overview Canvas - -Purpose: show the entire flow from opportunity generation to attractiveness placement -to focus portfolio decision. - -Required fields: - -- Name. -- Date. -- Title: `Market Opportunity Overview`. -- Market opportunity definition: `application + customer`. -- Left panel: **Market Opportunity Set**. -- Middle panel: **Attractiveness Map**. -- Right panel: **Focus Portfolio Map**. - -### Market Opportunity Set Panel - -Contains market opportunity cards generated from: - -```text -application + customer = market opportunity -``` - -Each card should have: - -| Field | Description | -|---|---| -| ID | Short stable label such as MO-1, MO-2, MO-3 | -| Application | What the core ability enables | -| Customer segment | Who needs that application | -| Market opportunity | Combined application + customer | - -### Attractiveness Map Panel - -Axes: - -| Axis | Direction | Rating Levels | -|---|---|---| -| Potential | vertical | Low, Mid, High, Super High | -| Challenge | horizontal | Low, Mid, High, Super High | - -Zones: - -| Zone | Meaning | -|---|---| -| Gold Mine | High potential with relatively low challenge | -| Quick Win | Lower potential with relatively low challenge | -| Moon Shot | High potential with high challenge | -| Questionable | Lower potential with high challenge | - -### Focus Portfolio Map Panel - -Nested decision areas: - -| Area | Meaning | -|---|---| -| Pursue now | Active focus or active parallel pursuit | -| Keep open | Preserve option value without fully committing | -| Place in storage | Document but do not actively preserve now | - -Cards placed here must identify whether they are primary, backup, growth, or storage -options. - -## 2. Opportunity Set Builder - -Purpose: generate market opportunities by combining core abilities, applications, and -customer segments. - -Required fields: - -- Name. -- Date. -- Title: `Generate Your Market Opportunity Set`. -- Core abilities or technological elements. -- Applications. -- Customers. -- Market opportunities. - -### Core Abilities Table - -List the venture's core abilities or technological elements. Characterize each by -function and properties, independent from the envisioned product. - -| Ability ID | Core Ability or Technological Element | Function | Key Properties | Evidence / Notes | -|---|---|---|---|---| -| A1 | | | | | -| A2 | | | | | -| A3 | | | | | -| A4 | | | | | - -### Market Opportunity Generation Table - -Use each row to combine an application with a customer segment. - -| Opportunity ID | Ability ID(s) | Application | Customer Segment | Finer Customer Segmentation | Market Opportunity | -|---|---|---|---|---|---| -| MO-1 | | | | | | -| MO-2 | | | | | | -| MO-3 | | | | | | - -Generation prompts: - -- Which applications can the core abilities offer? -- Which customers may need each application? -- Can the customer group be segmented more precisely? -- Which combinations should be evaluated next? - -## 3. Attractiveness Evaluator - -Purpose: evaluate each market opportunity by potential and challenge, then place it -on the attractiveness map. - -Required fields: - -- Name. -- Date. -- Title: `Evaluate Market Opportunity Attractiveness`. -- Market Opportunity. -- Potential. -- Challenge. -- Overall Potential. -- Overall Challenge. -- Attractiveness Map zone. - -Use this canvas once for every market opportunity being evaluated. - -### Potential Ratings - -| Potential Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Compelling Reason to Buy | Unmet need; effective solution; better than current solutions | Low / Mid / High / Super High | | -| Market Volume | Current market size; expected growth | Low / Mid / High / Super High | | -| Economic Viability | Margins (value vs. cost); customers' ability to pay; customer stickiness | Low / Mid / High / Super High | | - -### Challenge Ratings - -| Challenge Dimension | Subcriteria | Rating | Evidence / Assumptions | -|---|---|---|---| -| Implementation Obstacles | Product development difficulties; sales and distribution difficulties; funding challenges | Low / Mid / High / Super High | | -| Time to Revenue | Development time; time between product and market readiness; length of sales cycle | Low / Mid / High / Super High | | -| External Risks | Competitive threat; third-party dependencies; barriers to adoption | Low / Mid / High / Super High | | - -### Overall Placement - -| Market Opportunity | Overall Potential | Overall Challenge | Map Zone | Rationale | -|---|---|---|---|---| -| | Low / Mid / High / Super High | Low / Mid / High / Super High | Gold Mine / Quick Win / Moon Shot / Questionable | | - -## 4. Focus Portfolio Planner - -Purpose: design the focus strategy around one primary market opportunity while -preserving backup and growth options. - -Required fields: - -- Name. -- Date. -- Title: `Design Your Focus Strategy`. -- Primary Market Opportunity. -- Other attractive market opportunities. -- Product relatedness. -- Market relatedness. -- Suitable as backup option. -- Suitable as growth option. -- Action decision: pursue now, keep open, or place in storage. - -### Step I: Choose Primary Market Opportunity - -Choose the primary market opportunity based on the attractiveness map. - -| Primary Market Opportunity | Attractiveness Map Position | Why This Is Primary | Main Evidence | Main Risks | -|---|---|---|---|---| -| | | | | | - -### Step II: Examine Other Attractive Opportunities - -For each other attractive market opportunity, compare it with the primary opportunity. - -| Option ID | Market Opportunity | Product Relatedness | Product Relatedness Rationale | Market Relatedness | Market Relatedness Rationale | Risk Overlap With Primary | -|---|---|---|---|---|---|---| -| MO-2 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-3 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | -| MO-4 | | Low / Mid / High | | Low / Mid / High | | Low / Mid / High | - -Product relatedness asks how much the products share: - -- Technological competences. -- Required resources. -- Necessary networks. - -Market relatedness asks how much the customers share: - -- Values and benefits. -- Sales channels. -- Word-of-mouth paths. - -### Step III: Classify and Decide - -Use this table to mark whether each option is suitable as backup, growth, both, or -neither, then decide what to do with it. - -| Option ID | Market Opportunity | Backup Option? | Growth Option? | Action | Rationale | -|---|---|---|---|---|---| -| MO-2 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-3 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | -| MO-4 | | Yes / No | Yes / No | Pursue now / Keep open / Place in storage | | - -Definitions: - -- **Backup Option**: an attractive market opportunity that does not share major risks - with the primary market opportunity and can support a change in direction. -- **Growth Option**: an attractive market opportunity that can create additional value - if the primary opportunity succeeds. - -Strategy rule: - -- Keep at least one Backup Option open. -- Keep at least one Growth Option open. -- Decide whether any option is worth pursuing now. -- Place the rest in storage. - -### Final Focus Strategy Summary - -| Category | Market Opportunity | Decision | Why | -|---|---|---|---| -| Primary | | Pursue now | | -| Backup | | Keep open / Pursue now | | -| Growth | | Keep open / Pursue now | | -| Storage | | Place in storage | | diff --git a/skills/market-opportunity/references/output-formats.md b/skills/market-opportunity/references/output-formats.md deleted file mode 100644 index ee145a61..00000000 --- a/skills/market-opportunity/references/output-formats.md +++ /dev/null @@ -1,143 +0,0 @@ -# Output Formats - -Use the same canonical four-artifact structure in every format. Use neutral artifact -names in titles and headings. - -## Markdown Blank Canvas Set - -Use when the user wants editable text tables. - -Required sections: - -```markdown -# Market Opportunity - -## 1. Opportunity Overview Canvas -[overview tables] - -## 2. Opportunity Set Builder -[blank abilities and opportunity generation tables] - -## 3. Attractiveness Evaluator -[one blank evaluator per opportunity, or reusable blank evaluator] - -## 4. Focus Portfolio Planner -[blank primary, relatedness, backup/growth, and action decision tables] -``` - -## Markdown Filled Canvas Set - -Use when the user provides a venture, technology, product, or opportunity set. - -Required sections: - -```markdown -# Market Opportunity: [Venture/Product] - -## 1. Opportunity Overview Canvas -- Market opportunity cards. -- Attractiveness placements. -- Focus portfolio decisions. - -## 2. Opportunity Set Builder -- Core abilities. -- Applications. -- Customer segments. -- Generated market opportunities. - -## 3. Attractiveness Evaluator -- One evaluation table per selected market opportunity. -- Overall potential, overall challenge, and map zone. - -## 4. Focus Portfolio Planner -- Primary market opportunity. -- Option comparison by product and market relatedness. -- Backup/growth classification. -- Pursue now / keep open / place in storage decisions. - -## Strategy Implications -- Product/technology modularity. -- IP and defensibility. -- Hiring/capability needs. -- Stakeholder and investor alignment. -- Brand and communication implications. -- Experiments and next evidence to collect. -``` - -## Visual or Printable Canvas - -Use when the user asks for printable templates, visual canvases, an HTML file, a PDF, -or a slide-ready output. - -Requirements: - -- Produce four separate pages or sections. -- Preserve the same layout logic: - - Overview: three panels side by side. - - Opportunity Set Builder: abilities at top; applications and customers below. - - Attractiveness Evaluator: potential on left, challenge on right, overall ratings at - the bottom. - - Focus Portfolio Planner: primary opportunity at top, option columns below, relatedness - rows, backup/growth rows, action rows at bottom. -- Use neutral artifact titles. -- Include `Name` and `Date` fields when producing a printable artifact. -- Include editable blank spaces or filled content depending on the requested mode. - -Recommended visual names: - -| Original Function | Use This Title | -|---|---| -| Full opportunity overview | Market Opportunity Overview | -| Generate opportunity set | Opportunity Set Builder | -| Evaluate attractiveness | Market Opportunity Attractiveness | -| Design focus strategy | Focus Strategy Planner | - -## Compact Decision Memo - -Use when the user wants a concise strategic answer rather than the full canvas set. - -Required sections: - -```markdown -## Recommendation -[Primary market opportunity and why] - -## Opportunity Portfolio -| Category | Opportunity | Decision | Why | - -## Key Ratings -| Opportunity | Potential | Challenge | Zone | - -## Risks and Open Assumptions -[Most important evidence gaps] - -## Next Tests -[Lean experiments or research needed] -``` - -## Spreadsheet-Friendly Format - -Use when the user wants to paste into Sheets/Excel. - -Create four CSV-style tables: - -1. `opportunity_set` -2. `attractiveness_ratings` -3. `map_placements` -4. `focus_portfolio` - -Minimum columns: - -```text -opportunity_set: -opportunity_id,ability_ids,application,customer_segment,finer_segment,market_opportunity - -attractiveness_ratings: -opportunity_id,potential_compelling_reason,potential_market_volume,potential_economic_viability,overall_potential,challenge_implementation,challenge_time_to_revenue,challenge_external_risks,overall_challenge,evidence_notes - -map_placements: -opportunity_id,overall_potential,overall_challenge,map_zone - -focus_portfolio: -opportunity_id,role,product_relatedness,market_relatedness,risk_overlap,backup_option,growth_option,action,rationale -``` diff --git a/skills/market-opportunity/references/rating-and-decision-rules.md b/skills/market-opportunity/references/rating-and-decision-rules.md deleted file mode 100644 index fdfe3093..00000000 --- a/skills/market-opportunity/references/rating-and-decision-rules.md +++ /dev/null @@ -1,250 +0,0 @@ -# Rating and Decision Rules - -Use these rules to keep opportunity ratings consistent. - -## Rating Scale - -Use only these four levels: - -```text -Low / Mid / High / Super High -``` - -For challenge dimensions, higher means more difficult, slower, riskier, or more -resource-intensive. Low challenge is good. - -## Potential Ratings - -### Compelling Reason to Buy - -Rate based on: - -- Strength of unmet need. -- Whether the solution effectively addresses the need. -- Whether it is better than current alternatives. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak pain, unclear need, or little advantage over alternatives | -| Mid | Recognizable need but limited urgency or differentiation | -| High | Clear need, strong solution fit, meaningful advantage | -| Super High | Urgent need, strong willingness to switch or buy, clear superiority | - -### Market Volume - -Rate based on: - -- Current market size. -- Expected growth. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Small or shrinking reachable market | -| Mid | Meaningful niche or uncertain growth | -| High | Large reachable market or strong growth | -| Super High | Very large market with strong growth and credible reach | - -### Economic Viability - -Rate based on: - -- Margins: value created versus cost to deliver. -- Customers' ability to pay. -- Customer stickiness. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Weak margins, low willingness or ability to pay, low retention potential | -| Mid | Economics may work but are not yet proven | -| High | Attractive value/cost relationship and credible willingness to pay | -| Super High | Strong margins, high willingness to pay, strong retention or lock-in | - -## Challenge Ratings - -### Implementation Obstacles - -Rate based on: - -- Product development difficulties. -- Sales and distribution difficulties. -- Funding challenges. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Straightforward product, go-to-market, and funding path | -| Mid | Some execution difficulty, but manageable | -| High | Significant product, distribution, or funding obstacles | -| Super High | Very difficult execution path or major resource gap | - -### Time to Revenue - -Rate based on: - -- Development time. -- Gap between product readiness and market readiness. -- Length of sales cycle. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Revenue can plausibly arrive quickly | -| Mid | Moderate path to revenue | -| High | Long development, readiness, or sales cycle | -| Super High | Very long or uncertain time to revenue | - -### External Risks - -Rate based on: - -- Competitive threat. -- Third-party dependencies. -- Barriers to adoption. - -Guidance: - -| Rating | Meaning | -|---|---| -| Low | Limited external risk or manageable dependencies | -| Mid | Some competitive, dependency, or adoption risk | -| High | Serious external risks that could block progress | -| Super High | External risks may dominate the opportunity | - -## Overall Potential and Challenge - -Do not compute mechanically unless the user asks for numeric scoring. Use evidence and -judgment. - -Default aggregation: - -- Overall Potential should reflect the weakest critical potential dimension. A huge - market is not enough if there is no compelling reason to buy. -- Overall Challenge should reflect the hardest blocking challenge. A simple build is - not enough if revenue requires a multi-year sales cycle. - -If using numeric support: - -```text -Low = 1 -Mid = 2 -High = 3 -Super High = 4 -``` - -Use the rounded average as a starting point, then adjust for blockers and explain the -adjustment. - -## Attractiveness Map Zone Rules - -| Overall Potential | Overall Challenge | Zone | -|---|---|---| -| High or Super High | Low or Mid | Gold Mine | -| Low or Mid | Low or Mid | Quick Win | -| High or Super High | High or Super High | Moon Shot | -| Low or Mid | High or Super High | Questionable | - -Interpretation: - -- **Gold Mine**: strongest candidate for primary focus. -- **Quick Win**: potentially useful for learning, early traction, or stepping stones. -- **Moon Shot**: valuable but difficult; may require capital, patience, or unique assets. -- **Questionable**: weak candidate unless strategic reasons or new evidence change the view. - -## Primary Market Opportunity Rules - -Select the primary opportunity by weighing: - -- Attractiveness map zone. -- Strength of evidence. -- Founder/team fit. -- Ability to test assumptions. -- Strategic control and defensibility. -- Fit with resource constraints. - -Default preference: - -1. Gold Mine with strong evidence. -2. Gold Mine with evidence gaps but testable assumptions. -3. Quick Win if it creates learning, revenue, or capability for a larger path. -4. Moon Shot only if the upside is large enough and the team has unusual advantages. -5. Questionable only if the user explicitly has strategic reasons. - -## Backup Option Rules - -A backup option should be attractive and should not share major risks with the primary -opportunity. - -Good backup options often differ on: - -- Customer segment. -- Sales channel. -- Adoption barrier. -- Regulatory pathway. -- Revenue model. -- Critical dependency. - -Do not label an option as backup merely because it is related. If it fails for the same -reason the primary fails, it is not a useful backup. - -## Growth Option Rules - -A growth option should be attractive and should let the venture create additional value -after or alongside the primary opportunity. - -Good growth options often share: - -- Technology. -- Capabilities. -- Customer relationships. -- Distribution. -- Brand credibility. -- Data or network effects. - -High relatedness makes a growth option more plausible. Very low relatedness usually -means the opportunity is diversification, not a near-term growth option. - -## Action Decision Rules - -### Pursue Now - -Use when: - -- The option is primary, or -- The option is highly attractive, resources permit parallel pursuit, and pursuing it - does not dilute the primary focus. - -### Keep Open - -Use when: - -- The option has strategic value as backup or growth. -- The cost of preserving it is modest. -- It requires monitoring, lightweight experiments, modular design choices, IP claims, - partner conversations, or relationship maintenance. - -### Place in Storage - -Use when: - -- The option is not attractive enough now. -- The opportunity is too unrelated or costly to preserve. -- Evidence is too weak. -- It is worth remembering but not worth spending active effort on. - -## Evidence Discipline - -For each rating, distinguish: - -- Evidence: facts, interviews, data, observed behavior, signed interest, market numbers. -- Assumptions: plausible but unvalidated beliefs. -- Unknowns: missing information that could change the rating. - -When evidence is weak, phrase the output as a hypothesis and propose the next test. diff --git a/skills/market-orientation-audit/SKILL.md b/skills/market-orientation-audit/SKILL.md deleted file mode 100644 index 17642684..00000000 --- a/skills/market-orientation-audit/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: market-orientation-audit -description: >- - Audit whether an organization is truly market oriented using intelligence generation, - intelligence dissemination, and responsiveness. Use for customer-centricity, marketing - culture, organizational diagnosis, market sensing, and scorecard-based improvement plans. ---- - - - -# Market Orientation Audit - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-orientation-audit` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user wants to diagnose how well an organization senses markets, shares customer/competitor insight internally, and acts on that insight. - -Do not use it for brand health, campaign evaluation, or product-market fit unless the question is specifically about organizational market orientation. - -## Core Model - -Market orientation is an organization-wide culture and operating system for creating customer value. It has three dimensions: - -- **Intelligence generation**: how the organization detects customer, competitor, collaborator, technology, and regulatory changes. -- **Intelligence dissemination**: how quickly and effectively insight spreads across functions. -- **Responsiveness**: how fast and well the organization acts on market intelligence. - -## Scorecard - -Use a 1-5 scale: - -- 5 = Strongly agree -- 4 = Agree -- 3 = Neither agree nor disagree -- 2 = Disagree -- 1 = Strongly disagree - -Each dimension has 8 items. Dimension scoring: - -- 29-40 = High -- 20-28 = Moderate -- 8-19 = Low - -Total scoring: - -- 86-120 = High -- 60-85 = Moderate -- 24-59 = Low - -### Intelligence Generation - -1. We have interdepartmental meetings at least once a quarter to discuss market trends and developments. -2. We are quick to detect fundamental shifts in our industry, such as competition, technology, or regulation. -3. We periodically review the likely effect of environmental changes on customers. -4. We are fast to detect changes in customer product and service preferences. -5. People discuss customers' future needs with other functions or departments. -6. We do a lot of in-house market research. -7. We survey key customers at least once a year to assess product and service quality. -8. We meet key clients at least once a year to learn what products or services they will need in the future. - -### Intelligence Dissemination - -1. When something important happens to a major customer or market, the whole business knows quickly. -2. When one department learns something important about competitors, it quickly alerts other departments. -3. We would never ignore changes in customer product or service needs. -4. When customers want a product or service modification, involved teams make concerted efforts to respond. -5. We periodically review product or service development to ensure it aligns with key customer needs. -6. We have communication systems that speed dissemination of important customer-related information. -7. All functions and departments are responsive to each other's needs and requests. -8. When a customer complains or gives feedback, we quickly share it with anyone who can act on it. - -### Responsiveness - -1. It takes very little time to decide how to respond to competitor product or service changes. -2. We can implement new ideas, marketing plans, product redesigns, or service enhancements in a timely fashion. -3. Several functions periodically plan responses to changes in the business environment. -4. If a major competitor aggressively targeted a key customer, we would consider a response immediately. -5. We quickly act on customer complaints and feedback. -6. Customer-facing employees have latitude to solve customer problems without excessive red tape. -7. People here tend to talk more about opportunities than problems. -8. When we see a new opportunity to create customer value, we act quickly. - -## Workflow - -1. Collect scores from the user or run a facilitated self-assessment. -2. Compute dimension totals and total score. -3. Identify the weakest dimension and the lowest individual items. -4. Diagnose root causes across incentives, structure, tooling, decision rights, data access, rituals, and culture. -5. Translate findings into operating changes, not just research recommendations. -6. Define a 30/60/90-day improvement plan and measurement cadence. - -## Output - -Return: - -- **Score Summary**: dimension scores, total score, high/moderate/low rating. -- **Pattern Diagnosis**: what the scores imply about market sensing, sharing, and action. -- **Lowest Items**: the specific behaviors causing the largest gap. -- **Organizational Hurdles**: structure, incentives, data, rituals, authority, culture. -- **Improvement Plan**: 30/60/90-day actions. -- **Operating Metrics**: indicators to track improvement. - -## Quality Bar - -- Do not equate customer-facing friendliness with market orientation. -- Treat market orientation as cross-functional. -- Separate collecting insight from acting on insight. -- Recommend concrete operating changes, not generic "talk to customers more" advice. diff --git a/skills/market-orientation-audit/SKILL.md.tmpl b/skills/market-orientation-audit/SKILL.md.tmpl deleted file mode 100644 index 26ada885..00000000 --- a/skills/market-orientation-audit/SKILL.md.tmpl +++ /dev/null @@ -1,104 +0,0 @@ ---- -name: market-orientation-audit -description: >- - Audit whether an organization is truly market oriented using intelligence generation, - intelligence dissemination, and responsiveness. Use for customer-centricity, marketing - culture, organizational diagnosis, market sensing, and scorecard-based improvement plans. ---- -# Market Orientation Audit - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when the user wants to diagnose how well an organization senses markets, shares customer/competitor insight internally, and acts on that insight. - -Do not use it for brand health, campaign evaluation, or product-market fit unless the question is specifically about organizational market orientation. - -## Core Model - -Market orientation is an organization-wide culture and operating system for creating customer value. It has three dimensions: - -- **Intelligence generation**: how the organization detects customer, competitor, collaborator, technology, and regulatory changes. -- **Intelligence dissemination**: how quickly and effectively insight spreads across functions. -- **Responsiveness**: how fast and well the organization acts on market intelligence. - -## Scorecard - -Use a 1-5 scale: - -- 5 = Strongly agree -- 4 = Agree -- 3 = Neither agree nor disagree -- 2 = Disagree -- 1 = Strongly disagree - -Each dimension has 8 items. Dimension scoring: - -- 29-40 = High -- 20-28 = Moderate -- 8-19 = Low - -Total scoring: - -- 86-120 = High -- 60-85 = Moderate -- 24-59 = Low - -### Intelligence Generation - -1. We have interdepartmental meetings at least once a quarter to discuss market trends and developments. -2. We are quick to detect fundamental shifts in our industry, such as competition, technology, or regulation. -3. We periodically review the likely effect of environmental changes on customers. -4. We are fast to detect changes in customer product and service preferences. -5. People discuss customers' future needs with other functions or departments. -6. We do a lot of in-house market research. -7. We survey key customers at least once a year to assess product and service quality. -8. We meet key clients at least once a year to learn what products or services they will need in the future. - -### Intelligence Dissemination - -1. When something important happens to a major customer or market, the whole business knows quickly. -2. When one department learns something important about competitors, it quickly alerts other departments. -3. We would never ignore changes in customer product or service needs. -4. When customers want a product or service modification, involved teams make concerted efforts to respond. -5. We periodically review product or service development to ensure it aligns with key customer needs. -6. We have communication systems that speed dissemination of important customer-related information. -7. All functions and departments are responsive to each other's needs and requests. -8. When a customer complains or gives feedback, we quickly share it with anyone who can act on it. - -### Responsiveness - -1. It takes very little time to decide how to respond to competitor product or service changes. -2. We can implement new ideas, marketing plans, product redesigns, or service enhancements in a timely fashion. -3. Several functions periodically plan responses to changes in the business environment. -4. If a major competitor aggressively targeted a key customer, we would consider a response immediately. -5. We quickly act on customer complaints and feedback. -6. Customer-facing employees have latitude to solve customer problems without excessive red tape. -7. People here tend to talk more about opportunities than problems. -8. When we see a new opportunity to create customer value, we act quickly. - -## Workflow - -1. Collect scores from the user or run a facilitated self-assessment. -2. Compute dimension totals and total score. -3. Identify the weakest dimension and the lowest individual items. -4. Diagnose root causes across incentives, structure, tooling, decision rights, data access, rituals, and culture. -5. Translate findings into operating changes, not just research recommendations. -6. Define a 30/60/90-day improvement plan and measurement cadence. - -## Output - -Return: - -- **Score Summary**: dimension scores, total score, high/moderate/low rating. -- **Pattern Diagnosis**: what the scores imply about market sensing, sharing, and action. -- **Lowest Items**: the specific behaviors causing the largest gap. -- **Organizational Hurdles**: structure, incentives, data, rituals, authority, culture. -- **Improvement Plan**: 30/60/90-day actions. -- **Operating Metrics**: indicators to track improvement. - -## Quality Bar - -- Do not equate customer-facing friendliness with market orientation. -- Treat market orientation as cross-functional. -- Separate collecting insight from acting on insight. -- Recommend concrete operating changes, not generic "talk to customers more" advice. diff --git a/skills/market-orientation-audit/agents/openai.yaml b/skills/market-orientation-audit/agents/openai.yaml deleted file mode 100644 index 45d74994..00000000 --- a/skills/market-orientation-audit/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market Orientation Audit" - short_description: "Audit whether an organization is truly market oriented using intelligence generation, intelligence dissemination,..." - brand_color: "#EA580C" - default_prompt: "Use $market-orientation-audit with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/market-orientation-audit/productize.json b/skills/market-orientation-audit/productize.json deleted file mode 100644 index 360a7a9c..00000000 --- a/skills/market-orientation-audit/productize.json +++ /dev/null @@ -1,44 +0,0 @@ -{ - "title": "Market Orientation Audit", - "category": "Marketing", - "tags": [ - "marketing-strategy", - "market-orientation", - "customer-centricity", - "market-sensing", - "scorecard", - "organizational-diagnosis", - "market-orientation-audit", - "market", - "orientation", - "audit", - "marketing", - "whether", - "organization" - ], - "lifecycle": "Strategize", - "use_when": "Audit whether an organization is truly market oriented using intelligence generation, intelligence dissemination, and responsiveness. Use for customer-centricity, marketing culture, organizational diagnosis, market sensing, and scorecard-based improvement plans.", - "do_not_use_when": "Do not use Market Orientation Audit when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "market-orientation-audit", - "market", - "orientation", - "audit", - "marketing", - "whether", - "organization" - ], - "framework_fit": "Market Orientation Audit fits Marketing work in the Strategize lifecycle when the user needs Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Market Orientation Audit as generic Marketing advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Market Orientation Audit when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $market-orientation-audit to turn this market context into a decision-ready Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Market Orientation Audit strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/market-requirements-from-strategic-market-inputs/SKILL.md b/skills/market-requirements-from-strategic-market-inputs/SKILL.md deleted file mode 100644 index 88fc1676..00000000 --- a/skills/market-requirements-from-strategic-market-inputs/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: market-requirements-from-strategic-market-inputs -description: >- - Market requirements from strategic market inputs. Use when the user needs a product workflow - for product strategy related to market requirements from strategic market inputs. Trigger - terms: product-management, market-research, strategy, MRD. ---- - - - -# Market requirements from strategic market inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-requirements-from-strategic-market-inputs` -- **Lifecycle**: Strategize -- **Category**: Discovery -- **Primary artifact**: Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Market requirements from strategic market inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MARKET_INDUSTRY}} -- {{PROBLEM_UNMET_NEED}} -- {{TARGET_USER_BUYER}} -- {{CURRENT_ALTERNATIVES}} -- {{COMPANY_ROLE_VISION_ADVANTAGE}} -- {{EXTERNAL_FACTORS}} -- {{OUTPUT_REQUEST}} - - -GOAL -Produce a high-quality deliverable for: Market requirements from strategic market inputs. -Success metric: -- Gathers required MRD inputs via a structured question flow. -- Produces decision-ready MRD sections only after the user confirms โ€œReady to draft.โ€ -- Keeps analysis concise, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; ask one question at a time until the user says **โ€œReady to draft.โ€** -- Do not draft any MRD section before the user explicitly says **โ€œReady to draft.โ€** -- After the user selects the output (Aโ€“D), produce that section only and pause for feedback. -- Use links for citations; state assumptions explicitly. -- No emojis. No JSON output. - -FORMAT -Return exactly this structure: - - -Letโ€™s co-create a Market Requirements Document. Iโ€™ll ask a few questions to gather context and then generate a draft. First up: What market or industry are you exploring? - - - -[Your single next question based on the most recent answer] - - -[When user says โ€œReady to draft,โ€ respond with exactly one of the requested MRD sections using the MRD Output Format headings.] - -FAILURE -- Output drafts MRD sections before user says โ€œReady to draft.โ€ -- More than one question is asked at a time. -- Output does not follow the selected section from Aโ€“D. -- Missing citations/assumptions where needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/market-requirements-from-strategic-market-inputs/SKILL.md.tmpl b/skills/market-requirements-from-strategic-market-inputs/SKILL.md.tmpl deleted file mode 100644 index 6bbf8a7f..00000000 --- a/skills/market-requirements-from-strategic-market-inputs/SKILL.md.tmpl +++ /dev/null @@ -1,69 +0,0 @@ ---- -name: market-requirements-from-strategic-market-inputs -description: >- - Market requirements from strategic market inputs. Use when the user needs a product workflow - for product strategy related to market requirements from strategic market inputs. Trigger - terms: product-management, market-research, strategy, MRD. ---- -# Market requirements from strategic market inputs - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Market requirements from strategic market inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MARKET_INDUSTRY}} -- {{PROBLEM_UNMET_NEED}} -- {{TARGET_USER_BUYER}} -- {{CURRENT_ALTERNATIVES}} -- {{COMPANY_ROLE_VISION_ADVANTAGE}} -- {{EXTERNAL_FACTORS}} -- {{OUTPUT_REQUEST}} - - -GOAL -Produce a high-quality deliverable for: Market requirements from strategic market inputs. -Success metric: -- Gathers required MRD inputs via a structured question flow. -- Produces decision-ready MRD sections only after the user confirms โ€œReady to draft.โ€ -- Keeps analysis concise, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; ask one question at a time until the user says **โ€œReady to draft.โ€** -- Do not draft any MRD section before the user explicitly says **โ€œReady to draft.โ€** -- After the user selects the output (Aโ€“D), produce that section only and pause for feedback. -- Use links for citations; state assumptions explicitly. -- No emojis. No JSON output. - -FORMAT -Return exactly this structure: - - -Letโ€™s co-create a Market Requirements Document. Iโ€™ll ask a few questions to gather context and then generate a draft. First up: What market or industry are you exploring? - - - -[Your single next question based on the most recent answer] - - -[When user says โ€œReady to draft,โ€ respond with exactly one of the requested MRD sections using the MRD Output Format headings.] - -FAILURE -- Output drafts MRD sections before user says โ€œReady to draft.โ€ -- More than one question is asked at a time. -- Output does not follow the selected section from Aโ€“D. -- Missing citations/assumptions where needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/market-requirements-from-strategic-market-inputs/agents/openai.yaml b/skills/market-requirements-from-strategic-market-inputs/agents/openai.yaml deleted file mode 100644 index eb7b0bcc..00000000 --- a/skills/market-requirements-from-strategic-market-inputs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market requirements from strategic market inputs" - short_description: "Market requirements from strategic market inputs. Use when the user needs a product workflow for product strategy..." - brand_color: "#0D9488" - default_prompt: "Use $market-requirements-from-strategic-market-inputs with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/market-requirements-from-strategic-market-inputs/productize.json b/skills/market-requirements-from-strategic-market-inputs/productize.json deleted file mode 100644 index 6be954bf..00000000 --- a/skills/market-requirements-from-strategic-market-inputs/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Market requirements from strategic market inputs", - "category": "Discovery", - "lifecycle": "Strategize", - "tags": [ - "market-requirements-from-strategic-market-inputs", - "market", - "requirements", - "strategic", - "inputs" - ], - "use_when": "Market requirements from strategic market inputs. Use when the user needs a product workflow for product strategy related to market requirements from strategic market inputs. Trigger terms: product-management, market-research, strategy, MRD.", - "do_not_use_when": "Do not use Market requirements from strategic market inputs when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "market-requirements-from-strategic-market-inputs", - "market", - "requirements", - "strategic", - "inputs" - ], - "framework_fit": "Market requirements from strategic market inputs fits Discovery work in the Strategize lifecycle when the user needs Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Market requirements from strategic market inputs as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Market requirements from strategic market inputs when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $market-requirements-from-strategic-market-inputs to turn this market context into a decision-ready Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Market requirements from strategic market inputs strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/market-sizing/SKILL.md b/skills/market-sizing/SKILL.md deleted file mode 100644 index 9d2b7121..00000000 --- a/skills/market-sizing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable - market, market-entry upside, or investor-ready opportunity size. ---- - - - -# Market Sizing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `market-sizing` -- **Lifecycle**: Strategize -- **Category**: Venture / 0-1 -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/market-sizing/SKILL.md.tmpl b/skills/market-sizing/SKILL.md.tmpl deleted file mode 100644 index 178d47a3..00000000 --- a/skills/market-sizing/SKILL.md.tmpl +++ /dev/null @@ -1,111 +0,0 @@ ---- -name: market-sizing -description: >- - Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable - market, market-entry upside, or investor-ready opportunity size. ---- -# Market Sizing - -{{PRODUCTIZE_PREAMBLE}} - -Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size. - -## Productize Contract - -- **Primary lifecycle**: Strategize -- **Supporting lifecycle**: none -- **Primary artifact**: TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications -- **Source method**: pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md - -## Method - -## Purpose -Estimate the Total Addressable Market (TAM), Serviceable Addressable Market (SAM), and Serviceable Obtainable Market (SOM) for a product. Includes both top-down and bottom-up estimation approaches, growth projections, and key assumptions to validate. - -## Instructions - -You are a strategic market analyst specializing in market sizing, opportunity assessment, and growth forecasting. - -### Input -Your task is to estimate the market size for **$ARGUMENTS** within the specified market constraints (geography, industry vertical, customer type, etc.). - -If the user provides market research, industry reports, financial data, or competitor information, read and analyze them directly. Use web search to find current market data, industry reports, and growth projections. - -### Analysis Steps (Think Step by Step) - -1. **Market Definition**: Define the market boundaries -- what problem space, which customer segments, what geography or constraints apply -2. **Top-Down Estimation**: Start from total industry size and narrow to the relevant slice -3. **Bottom-Up Estimation**: Build from unit economics (customers x price x frequency) to cross-validate -4. **SAM Scoping**: Identify which portion of TAM is realistically serviceable given product capabilities, channels, and constraints -5. **SOM Estimation**: Estimate achievable share in the next 1-3 years based on competitive position and go-to-market capacity -6. **Growth Projection**: Forecast how TAM, SAM, and SOM may evolve over the next 2-3 years -7. **Assumption Mapping**: Surface the key assumptions underlying each estimate - -### Output Structure - -**Market Definition** -- Problem space and customer need -- Geographic and segment boundaries -- Key constraints or scoping decisions - -**TAM (Total Addressable Market)** -- Top-down estimate with sources and reasoning -- Bottom-up estimate for cross-validation -- Reconciliation of the two approaches -- Current TAM value (annual revenue opportunity) - -**SAM (Serviceable Addressable Market)** -- Which portion of TAM the product can realistically serve -- Constraints: geography, language, channels, product capabilities, pricing tier -- SAM as percentage of TAM with reasoning - -**SOM (Serviceable Obtainable Market)** -- Realistic share achievable in 1-3 years -- Basis: competitive position, go-to-market capacity, current traction -- SOM as percentage of SAM with reasoning - -**Market Summary Table** - -| Metric | Current Estimate | 2-3 Year Projection | -|--------|-----------------|---------------------| -| TAM | | | -| SAM | | | -| SOM | | | - -**Growth Drivers & Trends** -- Key factors that could expand or contract the market -- Technology, regulatory, demographic, or behavioral shifts -- Emerging segments or adjacent markets - -**Key Assumptions & Risks** -- Critical assumptions behind each estimate (numbered) -- Confidence level for each (high / medium / low) -- How to validate the most uncertain assumptions -- What would materially change the estimates - -## Best Practices - -- Always provide both top-down and bottom-up estimates to triangulate -- Use web search for current industry data, analyst reports, and market benchmarks -- Cite sources for market data -- avoid unsupported numbers -- Be explicit about assumptions; label estimates vs. data -- Distinguish between value-based (revenue) and volume-based (users/units) sizing -- Consider currency and purchasing power parity for international markets -- Flag where estimates have wide confidence intervals -- Recommend specific data sources or research to sharpen estimates - ---- - -### Further Reading - -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Crossing the Chasm: The Ultimate Guide For PMs](https://www.productcompass.pm/p/crossing-the-chasm) -- [Product Innovation Masterclass](https://www.productcompass.pm/p/product-innovation-masterclass) (video course) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/market-sizing/agents/openai.yaml b/skills/market-sizing/agents/openai.yaml deleted file mode 100644 index bce3bb53..00000000 --- a/skills/market-sizing/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Market Sizing" - short_description: "Market Sizing. Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or..." - brand_color: "#0F766E" - default_prompt: "Use $market-sizing with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/market-sizing/productize.json b/skills/market-sizing/productize.json deleted file mode 100644 index 4383397e..00000000 --- a/skills/market-sizing/productize.json +++ /dev/null @@ -1,50 +0,0 @@ -{ - "title": "Market Sizing", - "category": "Venture / 0-1", - "lifecycle": "Strategize", - "tags": [ - "market-sizing", - "tam", - "sam", - "som", - "market-entry", - "investor", - "market", - "sizing", - "venture", - "use", - "estimating" - ], - "use_when": "Use when estimating TAM, SAM, SOM, addressable market, serviceable market, market-entry upside, or investor-ready opportunity size.", - "do_not_use_when": "Do not use Market Sizing when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications", - "routing_signals": [ - "market-sizing", - "tam", - "sam", - "som", - "market-entry", - "investor", - "when", - "estimating", - "addressable", - "market", - "serviceable", - "entry", - "upside", - "ready" - ], - "framework_fit": "Best when a product or market decision depends on top-down and bottom-up market size assumptions that must be made explicit.", - "failure_modes": [ - "Produces TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Market Sizing as generic Venture / 0-1 advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Market Sizing when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $market-sizing to turn this tam context into a decision-ready TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications.", - "expected_artifact": "TAM/SAM/SOM market sizing model with assumptions, confidence, and decision implications" - } - ], - "imported_from": "pm-skills-main/pm-market-research/skills/market-sizing/SKILL.md" -} diff --git a/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md b/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md deleted file mode 100644 index 1d0f8bda..00000000 --- a/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: mece-analysis-and-logical-tree-from-list-items -description: >- - MECE analysis and logical tree from list items. Use when the user needs a product workflow - for decision making related to mece analysis and logical tree from list items. Trigger - terms: pm, decision-making, mece, structured-thinking, frameworks. ---- - - - -# MECE analysis and logical tree from list items - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `mece-analysis-and-logical-tree-from-list-items` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **MECE analysis and logical tree from list items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{LIST_OF_ITEMS}} - - -GOAL -Evaluate `LIST_OF_ITEMS` for MECE quality and produce a logical tree that resolves overlaps/gaps. -Success metric: -- Clearly assesses mutual exclusivity and collective exhaustiveness. -- Identifies concrete overlaps and coverage gaps (if any). -- Produces a coherent tree structure reflecting corrected grouping logic. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Test pairwise overlap (mutual exclusivity). - 2. Test coverage gaps (collective exhaustiveness). - 3. Propose corrected structure and hierarchy. -- Keep conclusions grounded in the provided list; avoid unrelated frameworks unless necessary. -- If ambiguity exists in item definitions, state assumptions explicitly. -- Provide concise rationale, not hidden/internal chain-of-thought. - -FORMAT -Return exactly this structure: - - - -[State whether items are mutually exclusive, with specific overlap examples where relevant] - - -[State whether items are collectively exhaustive, with specific gap examples where relevant] - - -[Concise list of overlap issues and/or coverage gaps] - - - - -[MECE status: Fully MECE | Not MECE | Partially MECE] - -[Hierarchical tree showing corrected structure and item placement] - - - -FAILURE -- Required schema sections are missing or malformed. -- Mutual exclusivity or collective exhaustiveness assessment is absent. -- Logical tree is missing, unclear, or inconsistent with analysis findings. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md.tmpl b/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md.tmpl deleted file mode 100644 index 78c3ef13..00000000 --- a/skills/mece-analysis-and-logical-tree-from-list-items/SKILL.md.tmpl +++ /dev/null @@ -1,74 +0,0 @@ ---- -name: mece-analysis-and-logical-tree-from-list-items -description: >- - MECE analysis and logical tree from list items. Use when the user needs a product workflow - for decision making related to mece analysis and logical tree from list items. Trigger - terms: pm, decision-making, mece, structured-thinking, frameworks. ---- -# MECE analysis and logical tree from list items - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **MECE analysis and logical tree from list items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{LIST_OF_ITEMS}} - - -GOAL -Evaluate `LIST_OF_ITEMS` for MECE quality and produce a logical tree that resolves overlaps/gaps. -Success metric: -- Clearly assesses mutual exclusivity and collective exhaustiveness. -- Identifies concrete overlaps and coverage gaps (if any). -- Produces a coherent tree structure reflecting corrected grouping logic. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Test pairwise overlap (mutual exclusivity). - 2. Test coverage gaps (collective exhaustiveness). - 3. Propose corrected structure and hierarchy. -- Keep conclusions grounded in the provided list; avoid unrelated frameworks unless necessary. -- If ambiguity exists in item definitions, state assumptions explicitly. -- Provide concise rationale, not hidden/internal chain-of-thought. - -FORMAT -Return exactly this structure: - - - -[State whether items are mutually exclusive, with specific overlap examples where relevant] - - -[State whether items are collectively exhaustive, with specific gap examples where relevant] - - -[Concise list of overlap issues and/or coverage gaps] - - - - -[MECE status: Fully MECE | Not MECE | Partially MECE] - -[Hierarchical tree showing corrected structure and item placement] - - - -FAILURE -- Required schema sections are missing or malformed. -- Mutual exclusivity or collective exhaustiveness assessment is absent. -- Logical tree is missing, unclear, or inconsistent with analysis findings. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/mece-analysis-and-logical-tree-from-list-items/agents/openai.yaml b/skills/mece-analysis-and-logical-tree-from-list-items/agents/openai.yaml deleted file mode 100644 index 4499cdbf..00000000 --- a/skills/mece-analysis-and-logical-tree-from-list-items/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "MECE analysis and logical tree from list items" - short_description: "MECE analysis and logical tree from list items. Use when the user needs a product workflow for decision making..." - brand_color: "#059669" - default_prompt: "Use $mece-analysis-and-logical-tree-from-list-items with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/mece-analysis-and-logical-tree-from-list-items/productize.json b/skills/mece-analysis-and-logical-tree-from-list-items/productize.json deleted file mode 100644 index e31f523a..00000000 --- a/skills/mece-analysis-and-logical-tree-from-list-items/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "MECE analysis and logical tree from list items", - "category": "Strategy", - "lifecycle": "Think", - "tags": [ - "mece-analysis-and-logical-tree-from-list-items", - "mece", - "logical", - "tree", - "list", - "items" - ], - "use_when": "MECE analysis and logical tree from list items. Use when the user needs a product workflow for decision making related to mece analysis and logical tree from list items. Trigger terms: pm, decision-making, mece, structured-thinking, frameworks.", - "do_not_use_when": "Do not use MECE analysis and logical tree from list items when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step", - "routing_signals": [ - "mece-analysis-and-logical-tree-from-list-items", - "mece", - "logical", - "tree", - "list", - "items" - ], - "framework_fit": "MECE analysis and logical tree from list items fits Strategy work in the Think lifecycle when the user needs MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats MECE analysis and logical tree from list items as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from MECE analysis and logical tree from list items when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $mece-analysis-and-logical-tree-from-list-items to turn this mece context into a decision-ready MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step.", - "expected_artifact": "MECE analysis and logical tree from list items decision-framing brief with issue tree, assumptions, options, and recommended next step" - } - ] -} diff --git a/skills/meeting-agendas-from-meeting-descriptions/SKILL.md b/skills/meeting-agendas-from-meeting-descriptions/SKILL.md deleted file mode 100644 index b89b0233..00000000 --- a/skills/meeting-agendas-from-meeting-descriptions/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: meeting-agendas-from-meeting-descriptions -description: >- - Meeting agendas from meeting descriptions. Use when the user needs a product workflow for - project management related to meeting agendas from meeting descriptions. Trigger terms: - meetings, facilitation, planning, productivity. ---- - - - -# Meeting agendas from meeting descriptions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-agendas-from-meeting-descriptions` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Meeting agendas from meeting descriptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DESCRIPTION}} - - -GOAL -Produce a high-quality deliverable for: "Meeting agendas from meeting descriptions". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a meeting preparation output from `{{MEETING_DESCRIPTION}}` that includes: -- A clear purpose statement for the meeting. -- A structured agenda with allocated time per topic and key questions per topic. -- A practical process/flow for running the meeting to achieve the stated purpose. -- Internally reason from meeting goals, stakeholders, and constraints; return only the required final sections. - -FORMAT -Return exactly this structure: - - -[Clear and concise purpose statement] - - - -1. [Agenda Topic 1] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -2. [Agenda Topic 2] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -[Additional agenda topics] - - - -[Suggested process and flow for the meeting] - - -FAILURE -- Any required section (``, ``, ``) is missing or materially incomplete. -- Agenda items do not include both time allocation and key questions. -- Meeting flow/process is generic and not tied to the stated purpose. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/meeting-agendas-from-meeting-descriptions/SKILL.md.tmpl b/skills/meeting-agendas-from-meeting-descriptions/SKILL.md.tmpl deleted file mode 100644 index f1392629..00000000 --- a/skills/meeting-agendas-from-meeting-descriptions/SKILL.md.tmpl +++ /dev/null @@ -1,76 +0,0 @@ ---- -name: meeting-agendas-from-meeting-descriptions -description: >- - Meeting agendas from meeting descriptions. Use when the user needs a product workflow for - project management related to meeting agendas from meeting descriptions. Trigger terms: - meetings, facilitation, planning, productivity. ---- -# Meeting agendas from meeting descriptions - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Meeting agendas from meeting descriptions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_DESCRIPTION}} - - -GOAL -Produce a high-quality deliverable for: "Meeting agendas from meeting descriptions". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a meeting preparation output from `{{MEETING_DESCRIPTION}}` that includes: -- A clear purpose statement for the meeting. -- A structured agenda with allocated time per topic and key questions per topic. -- A practical process/flow for running the meeting to achieve the stated purpose. -- Internally reason from meeting goals, stakeholders, and constraints; return only the required final sections. - -FORMAT -Return exactly this structure: - - -[Clear and concise purpose statement] - - - -1. [Agenda Topic 1] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -2. [Agenda Topic 2] - [Allocated Time] -Key Questions: -- [Question 1] -- [Question 2] -... -[Additional agenda topics] - - - -[Suggested process and flow for the meeting] - - -FAILURE -- Any required section (``, ``, ``) is missing or materially incomplete. -- Agenda items do not include both time allocation and key questions. -- Meeting flow/process is generic and not tied to the stated purpose. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/meeting-agendas-from-meeting-descriptions/agents/openai.yaml b/skills/meeting-agendas-from-meeting-descriptions/agents/openai.yaml deleted file mode 100644 index a4926de0..00000000 --- a/skills/meeting-agendas-from-meeting-descriptions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Meeting agendas from meeting descriptions" - short_description: "Meeting agendas from meeting descriptions. Use when the user needs a product workflow for project management related..." - brand_color: "#7C3AED" - default_prompt: "Use $meeting-agendas-from-meeting-descriptions with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/meeting-agendas-from-meeting-descriptions/productize.json b/skills/meeting-agendas-from-meeting-descriptions/productize.json deleted file mode 100644 index a8a043df..00000000 --- a/skills/meeting-agendas-from-meeting-descriptions/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Meeting agendas from meeting descriptions", - "category": "Operations", - "lifecycle": "Plan", - "tags": [ - "meeting-agendas-from-meeting-descriptions", - "meeting", - "agendas", - "descriptions", - "project", - "management", - "operations" - ], - "use_when": "Meeting agendas from meeting descriptions. Use when the user needs a product workflow for project management related to meeting agendas from meeting descriptions. Trigger terms: meetings, facilitation, planning, productivity.", - "do_not_use_when": "Do not use Meeting agendas from meeting descriptions when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "meeting-agendas-from-meeting-descriptions", - "meeting", - "agendas", - "descriptions", - "project", - "management", - "operations" - ], - "framework_fit": "Meeting agendas from meeting descriptions fits Operations work in the Plan lifecycle when the user needs Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Meeting agendas from meeting descriptions as generic Operations advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Meeting agendas from meeting descriptions when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $meeting-agendas-from-meeting-descriptions to turn this meeting context into a decision-ready Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Meeting agendas from meeting descriptions delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md b/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md deleted file mode 100644 index 3656b570..00000000 --- a/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- - - - -# Meeting Outcome Planning and Stakeholder Alignment - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-outcome-planning-and-stakeholder-alignment` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md.tmpl b/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md.tmpl deleted file mode 100644 index 6a5019b7..00000000 --- a/skills/meeting-outcome-planning-and-stakeholder-alignment/SKILL.md.tmpl +++ /dev/null @@ -1,121 +0,0 @@ ---- -name: meeting-outcome-planning-and-stakeholder-alignment -description: >- - Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product - workflow for stakeholder management related to meeting outcome planning and stakeholder - alignment. Trigger terms: stakeholder-management, executive-communication, - meeting-facilitation, org-politics, decision-making. ---- -# Meeting Outcome Planning and Stakeholder Alignment - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Meeting Outcome Planning and Stakeholder Alignment**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Meeting Outcome Planning and Stakeholder Alignment". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Timebox intake and planning for PM meeting prep (default 5-15 minutes, ask only essential questions unless enough context already exists). -- Clarify outcome, decision need/decider, stakeholder map, risks/politics, constraints, and success criteria. -- Produce a copy-ready meeting plan that includes: -- TL;DR (`<=60` words). -- Meeting Brief with objective, type mix percentages (Information/Discovery/Discussion/Decision/Alignment), decision statement/decider, stakeholder map, time-boxed agenda, key messages/proofs, objections/counters, give-get plan, artifacts, and exit checklist. -- When a decision is required, include anti-groupthink mechanics: silent write or private input, private vote when appropriate, explicit dissent, devil's advocate, sequence control for speaker order, and a clear decision rule. -- Follow-up Email template with objective recap, covered points, decisions, open items, notes/links, and next checkpoint. -- Async alternative plan when a meeting is unnecessary (with steps, owners, deadlines). -- Apply edge-case logic: missing decider, pure info-share closure, high conflict handling, explicit assumptions. -- End with a 5-item read-aloud checklist: Goal, Decision/Decider, Stakeholders, Agenda times, Next steps. - -FORMAT -Return exactly this structure: - -TL;DR -[<=60 words] - -Meeting Brief -One-sentence objective: [text] -Type mix: Information [x]%, Discovery [x]%, Discussion [x]%, Decision [x]%, Alignment [x]% -Decision statement (if any): [text]. Decider: [name/role or None] -Stakeholder map: -| Attendee | Interest | Influence (H/M/L) | Likely concerns | Pre-wire plan | -| --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | -Agenda (time-boxed): -- 0-2 min: [text] -- [time]: [text] -- Final 3-5 min: [decisions/owners/dates or closure rationale] -Key messages & proofs: -- [bullet] -Likely objections & counters: -- [objection -> counter] -Decision quality controls: -- Private input: [yes/no + method] -- Devil's advocate / dissent owner: [name/role] -- Speaker order / sequence control: [plan] -- Private or public vote: [method] -- Decision rule: [rule] -Give-get plan: -- [offer vs ask] -Artifacts: -- [artifact, owner, send time] -Exit checklist: -- [decision captured] -- [DRI named] -- [dates agreed] -- [risks logged] -- [follow-up owner] - -Follow-up Email -Subject: [Outcome] - [Project/Topic], [Date] -Body: -- Objective recap: [text] -- What we covered: [bullets] -- Decisions: [decision / DRI / due date] -- Open items: [owner / next step / due date] -- Notes/Context: [links] -- Thank you & next checkpoint: [text] - -If Meeting Is Unnecessary (Async Plan) -- [step, owner, deadline] - -Assumptions -- [assumption or "None"] - -Read-Aloud Checklist -1. Goal: [text] -2. Decision/Decider: [text] -3. Stakeholders: [text] -4. Agenda times: [text] -5. Next steps: [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Type mix percentages are missing or not approximately 100%. -- No decision/decider handling when decision is required, or no async plan when meeting is unnecessary. -- Decision meetings omit dissent, private input/voting, speaker-order control, or decision rule when groupthink/conformity risk is present. -- Final 5-item read-aloud checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/meeting-outcome-planning-and-stakeholder-alignment/agents/openai.yaml b/skills/meeting-outcome-planning-and-stakeholder-alignment/agents/openai.yaml deleted file mode 100644 index d53a2048..00000000 --- a/skills/meeting-outcome-planning-and-stakeholder-alignment/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Meeting Outcome Planning and Stakeholder Alignment" - short_description: "Meeting Outcome Planning and Stakeholder Alignment. Use when the user needs a product workflow for stakeholder..." - brand_color: "#7C2D12" - default_prompt: "Use $meeting-outcome-planning-and-stakeholder-alignment with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/meeting-outcome-planning-and-stakeholder-alignment/productize.json b/skills/meeting-outcome-planning-and-stakeholder-alignment/productize.json deleted file mode 100644 index 7c050684..00000000 --- a/skills/meeting-outcome-planning-and-stakeholder-alignment/productize.json +++ /dev/null @@ -1,37 +0,0 @@ -{ - "title": "Meeting Outcome Planning and Stakeholder Alignment", - "category": "Decision Making", - "lifecycle": "Align", - "tags": [ - "meeting-outcome-planning-and-stakeholder-alignment", - "meeting", - "outcome", - "planning", - "stakeholder", - "alignment" - ], - "use_when": "Use when planning a meeting whose main purpose is to reach, align around, or prepare for a product or stakeholder decision.", - "do_not_use_when": "Do not use when the main risk is groupthink, polarization, conformity, or authority bias; use group-decision-making-quality-review for group decision-process design.", - "output_artifact": "Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up", - "routing_signals": [ - "meeting-outcome-planning-and-stakeholder-alignment", - "meeting", - "outcome", - "planning", - "stakeholder", - "alignment", - "align-around" - ], - "framework_fit": "Best when the product work is explicitly about decision making and the requested method fits Meeting Outcome Planning and Stakeholder Alignment.", - "failure_modes": [ - "Produces Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Meeting Outcome Planning and Stakeholder Alignment as generic Decision Making advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Meeting Outcome Planning and Stakeholder Alignment when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $meeting-outcome-planning-and-stakeholder-alignment to plan a decision meeting about cutting roadmap scope, including decider, agenda, dissent, private input, and decision rule.", - "expected_artifact": "Decision meeting plan with objective, decider, stakeholder map, agenda, anti-groupthink controls, decision rule, and follow-up" - } - ] -} diff --git a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md b/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md deleted file mode 100644 index 5d07baa1..00000000 --- a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: meeting-summaries-from-meeting-transcript-ideas-framework -description: >- - Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a - product workflow for presentation & communication related to meeting summaries from meeting - transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, - note-taking. ---- - - - -# Meeting summaries from meeting transcript (IDEAS framework) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `meeting-summaries-from-meeting-transcript-ideas-framework` -- **Lifecycle**: Align -- **Category**: Operations -- **Primary artifact**: Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Meeting summaries from meeting transcript (IDEAS framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Meeting summaries from meeting transcript (IDEAS framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are tasked with summarizing a meeting using the IDEAS framework. This framework helps organize the key points of a meeting into five categories: Insights, Decisions, Engagements, Actions, and Summary. Here's the meeting transcript you need to analyze: - - -{{MEETING_TRANSCRIPT}} - - -Please carefully read and analyze the meeting transcript. Then, summarize the meeting using the IDEAS framework as follows: - -1. Insights: Identify and list the main insights or important realizations that emerged during the meeting. -2. Decisions: Note any decisions that were made during the meeting. -3. Engagements: List any tasks or responsibilities that were assigned to specific individuals or teams. -4. Actions: Highlight any immediate actions that need to be taken as a result of the meeting. -5. Summary: Provide a brief overall summary of the meeting's impact and significance. - -When writing your summary, please be concise and focused. Aim to capture the most important points rather than trying to include every detail. Use bullet points for each category to make the summary easy to read and understand. - -Present your summary using the following format, enclosed in XML tags: - -Remember to focus on the most significant and relevant information for each category. Your goal is to provide a clear, organized, and useful summary of the meeting using the IDEAS framework. - - -FORMAT -Return exactly this structure: - - - -โ€ข [List insights here] - - - -โ€ข [List decisions here] - - - -โ€ข [List engagements here] - - - -โ€ข [List actions here] - - - -[Write a brief overall summary here] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md.tmpl b/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md.tmpl deleted file mode 100644 index c15346e5..00000000 --- a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/SKILL.md.tmpl +++ /dev/null @@ -1,93 +0,0 @@ ---- -name: meeting-summaries-from-meeting-transcript-ideas-framework -description: >- - Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a - product workflow for presentation & communication related to meeting summaries from meeting - transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, - note-taking. ---- -# Meeting summaries from meeting transcript (IDEAS framework) - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Meeting summaries from meeting transcript (IDEAS framework)**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{MEETING_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Meeting summaries from meeting transcript (IDEAS framework). -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are tasked with summarizing a meeting using the IDEAS framework. This framework helps organize the key points of a meeting into five categories: Insights, Decisions, Engagements, Actions, and Summary. Here's the meeting transcript you need to analyze: - - -{{MEETING_TRANSCRIPT}} - - -Please carefully read and analyze the meeting transcript. Then, summarize the meeting using the IDEAS framework as follows: - -1. Insights: Identify and list the main insights or important realizations that emerged during the meeting. -2. Decisions: Note any decisions that were made during the meeting. -3. Engagements: List any tasks or responsibilities that were assigned to specific individuals or teams. -4. Actions: Highlight any immediate actions that need to be taken as a result of the meeting. -5. Summary: Provide a brief overall summary of the meeting's impact and significance. - -When writing your summary, please be concise and focused. Aim to capture the most important points rather than trying to include every detail. Use bullet points for each category to make the summary easy to read and understand. - -Present your summary using the following format, enclosed in XML tags: - -Remember to focus on the most significant and relevant information for each category. Your goal is to provide a clear, organized, and useful summary of the meeting using the IDEAS framework. - - -FORMAT -Return exactly this structure: - - - -โ€ข [List insights here] - - - -โ€ข [List decisions here] - - - -โ€ข [List engagements here] - - - -โ€ข [List actions here] - - - -[Write a brief overall summary here] - - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/agents/openai.yaml b/skills/meeting-summaries-from-meeting-transcript-ideas-framework/agents/openai.yaml deleted file mode 100644 index 961b1503..00000000 --- a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Meeting summaries from meeting transcript (IDEAS framework)" - short_description: "Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a product workflow for..." - brand_color: "#7C3AED" - default_prompt: "Use $meeting-summaries-from-meeting-transcript-ideas-framework with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/productize.json b/skills/meeting-summaries-from-meeting-transcript-ideas-framework/productize.json deleted file mode 100644 index 458cc650..00000000 --- a/skills/meeting-summaries-from-meeting-transcript-ideas-framework/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Meeting summaries from meeting transcript (IDEAS framework)", - "category": "Operations", - "lifecycle": "Align", - "tags": [ - "meeting-summaries-from-meeting-transcript-ideas-framework", - "meeting", - "summaries", - "transcript", - "ideas", - "framework" - ], - "use_when": "Meeting summaries from meeting transcript (IDEAS framework). Use when the user needs a product workflow for presentation & communication related to meeting summaries from meeting transcript (ideas framework). Trigger terms: meetings, summarization, frameworks, note-taking.", - "do_not_use_when": "Do not use Meeting summaries from meeting transcript (IDEAS framework) when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "meeting-summaries-from-meeting-transcript-ideas-framework", - "meeting", - "summaries", - "transcript", - "ideas", - "framework" - ], - "framework_fit": "Meeting summaries from meeting transcript (IDEAS framework) fits Operations work in the Align lifecycle when the user needs Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Meeting summaries from meeting transcript (IDEAS framework) as generic Operations advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Meeting summaries from meeting transcript (IDEAS framework) when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $meeting-summaries-from-meeting-transcript-ideas-framework to turn this meeting context into a decision-ready Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Meeting summaries from meeting transcript (IDEAS framework) stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/message-framing-and-comms-plan-designer/SKILL.md b/skills/message-framing-and-comms-plan-designer/SKILL.md deleted file mode 100644 index 10e27875..00000000 --- a/skills/message-framing-and-comms-plan-designer/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: message-framing-and-comms-plan-designer -description: >- - Message Framing & Comms Plan Designer. Use when the user needs a product workflow for - stakeholder management related to message framing & comms plan designer. Trigger terms: - communication, executive-communication, messaging, stakeholder-management. ---- - - - -# Message Framing & Comms Plan Designer - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `message-framing-and-comms-plan-designer` -- **Lifecycle**: Design -- **Category**: Marketing -- **Primary artifact**: Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Message Framing & Comms Plan Designer**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Message Framing & Comms Plan Designer. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use provided facts, audience, goal, and writing sample to design a message framing and communication plan. -- Provide 2-3 viable framing options, each with a one-line rationale tied to credibility, logic, and audience emotion. -- Produce two concise drafts in the user's natural tone: -- `ICs` draft with context, changes, actions, and timeline (`<=180` words). -- `Execs` draft with BLUF, risks/asks, and decision needed (`<=120` words). -- Include a strong subject/headline and two Slack snippets (announcement + reminder). -- Provide a mini comms plan with channel sequence, owner, timing, emphasis, and CTA. -- Include a `What to Omit` noise-reduction list and exactly 3 success signals. - -FORMAT -Return exactly this structure: - -Frames & Rationale -- [Frame 1]: [one-line rationale] -- [Frame 2]: [one-line rationale] -- [Frame 3 if used]: [one-line rationale] - -Draft for ICs -Subject/Headline: [text] -[ICs draft <=180 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Draft for Execs -Subject/Headline: [text] -[Execs draft <=120 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Mini Comms Plan -| Step | Channel | Owner | Timing | Emphasis | CTA | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -What to Omit -- [item] - -Success Signals -1. [signal] -2. [signal] -3. [signal] - -FAILURE -- Any required section is missing or materially incomplete. -- ICs draft exceeds 180 words or Execs draft exceeds 120 words. -- Missing subject/headline or missing either Slack snippet type (announcement/reminder). -- Comms plan table is missing required columns or sequence logic. -- Success Signals are not exactly three measurable indicators. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/message-framing-and-comms-plan-designer/SKILL.md.tmpl b/skills/message-framing-and-comms-plan-designer/SKILL.md.tmpl deleted file mode 100644 index defc6ed8..00000000 --- a/skills/message-framing-and-comms-plan-designer/SKILL.md.tmpl +++ /dev/null @@ -1,89 +0,0 @@ ---- -name: message-framing-and-comms-plan-designer -description: >- - Message Framing & Comms Plan Designer. Use when the user needs a product workflow for - stakeholder management related to message framing & comms plan designer. Trigger terms: - communication, executive-communication, messaging, stakeholder-management. ---- -# Message Framing & Comms Plan Designer - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Message Framing & Comms Plan Designer**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Message Framing & Comms Plan Designer. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use provided facts, audience, goal, and writing sample to design a message framing and communication plan. -- Provide 2-3 viable framing options, each with a one-line rationale tied to credibility, logic, and audience emotion. -- Produce two concise drafts in the user's natural tone: -- `ICs` draft with context, changes, actions, and timeline (`<=180` words). -- `Execs` draft with BLUF, risks/asks, and decision needed (`<=120` words). -- Include a strong subject/headline and two Slack snippets (announcement + reminder). -- Provide a mini comms plan with channel sequence, owner, timing, emphasis, and CTA. -- Include a `What to Omit` noise-reduction list and exactly 3 success signals. - -FORMAT -Return exactly this structure: - -Frames & Rationale -- [Frame 1]: [one-line rationale] -- [Frame 2]: [one-line rationale] -- [Frame 3 if used]: [one-line rationale] - -Draft for ICs -Subject/Headline: [text] -[ICs draft <=180 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Draft for Execs -Subject/Headline: [text] -[Execs draft <=120 words] -Slack snippet (announcement): [text] -Slack snippet (reminder): [text] - -Mini Comms Plan -| Step | Channel | Owner | Timing | Emphasis | CTA | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -What to Omit -- [item] - -Success Signals -1. [signal] -2. [signal] -3. [signal] - -FAILURE -- Any required section is missing or materially incomplete. -- ICs draft exceeds 180 words or Execs draft exceeds 120 words. -- Missing subject/headline or missing either Slack snippet type (announcement/reminder). -- Comms plan table is missing required columns or sequence logic. -- Success Signals are not exactly three measurable indicators. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/message-framing-and-comms-plan-designer/agents/openai.yaml b/skills/message-framing-and-comms-plan-designer/agents/openai.yaml deleted file mode 100644 index 0b32c5f5..00000000 --- a/skills/message-framing-and-comms-plan-designer/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Message Framing & Comms Plan Designer" - short_description: "Message Framing & Comms Plan Designer. Use when the user needs a product workflow for stakeholder management related..." - brand_color: "#EA580C" - default_prompt: "Use $message-framing-and-comms-plan-designer with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/message-framing-and-comms-plan-designer/productize.json b/skills/message-framing-and-comms-plan-designer/productize.json deleted file mode 100644 index f6c93ac5..00000000 --- a/skills/message-framing-and-comms-plan-designer/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Message Framing & Comms Plan Designer", - "category": "Marketing", - "lifecycle": "Design", - "tags": [ - "message-framing-and-comms-plan-designer", - "message", - "framing", - "comms", - "plan", - "designer" - ], - "use_when": "Message Framing & Comms Plan Designer. Use when the user needs a product workflow for stakeholder management related to message framing & comms plan designer. Trigger terms: communication, executive-communication, messaging, stakeholder-management.", - "do_not_use_when": "Do not use Message Framing & Comms Plan Designer when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "message-framing-and-comms-plan-designer", - "message", - "framing", - "comms", - "plan", - "designer" - ], - "framework_fit": "Message Framing & Comms Plan Designer fits Marketing work in the Design lifecycle when the user needs Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Message Framing & Comms Plan Designer as generic Marketing advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Message Framing & Comms Plan Designer when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $message-framing-and-comms-plan-designer to turn this message context into a decision-ready Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Message Framing & Comms Plan Designer UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md b/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md deleted file mode 100644 index d742d045..00000000 --- a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- - - - -# Metric drops diagnosis with rigorous stepwise decomposition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metric-drops-diagnosis-with-rigorous-stepwise-decomposition` -- **Lifecycle**: Strategize -- **Category**: Analytics -- **Primary artifact**: Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md.tmpl b/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md.tmpl deleted file mode 100644 index d5ad77fb..00000000 --- a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/SKILL.md.tmpl +++ /dev/null @@ -1,111 +0,0 @@ ---- -name: metric-drops-diagnosis-with-rigorous-stepwise-decomposition -description: >- - Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a - product workflow for business analysis related to metric drops diagnosis with rigorous - stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis. ---- -# Metric drops diagnosis with rigorous stepwise decomposition - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Metric drops diagnosis with rigorous stepwise decomposition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{METRIC_NAME}} -- {{FORMULA}} -- {{BASELINE_VALUE}} -- {{CURRENT_VALUE}} -- {{TIMEFRAME}} -- {{COMPARISON_WINDOWS}} -- {{DATA_SOURCES}} -- {{SEGMENT_DIMENSIONS}} -- {{KNOWN_EVENTS}} - - -GOAL -Diagnose the root cause of a metric drop using stepwise decomposition from metric-level to driver-level to segment-level causes. -Success metric: -- Identifies whether the drop is real vs artifact. -- Isolates top driver(s), break timing, and highest-impact segment(s). -- Produces 1-3 testable hypotheses with confirm/refute criteria and next actions. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Analyze in this exact sequence: - 1. Confirm drop validity (artifact checks). - 2. Decompose metric into 2-3 drivers from formula. - 3. Trend drivers to find break timing/pattern. - 4. Segment culprit driver and rank impact. - 5. Compare bad vs stable segments. - 6. Produce 1-3 ranked, testable hypotheses. -- For each subproblem include: - - Goal - - Method (queries/breakdowns/plots) - - Decision rule - - Findings - - Next step -- Use explicit calculations where possible (delta or contribution attribution). -- If SQL schema is incomplete, provide minimal-field request plus pseudocode with placeholders. -- Always label confidence (`High`, `Med`, `Low`) and all assumptions. -- Do not stop at symptom-level statements; identify driver, segment, break date, and likely causal mechanism. - -FORMAT -Return exactly this structure: - - - -[Goal, method, decision rule, findings, next step] -[Include table: period -> metric -> numerator/denominator -> data quality signals] -[Verdict: Real drop | Measurement artifact | Baseline skew] - - -[Driver tree] -[Driver table: driver -> baseline -> current -> % change -> contribution] -[Top culprit driver(s)] - - -[Break-date analysis by driver: break date, pattern (step/gradual), confidence] -[Candidate correlates from KNOWN_EVENTS] - - -[Impact-ranked segment table: segment -> baseline -> current -> delta -> volume share -> impact score] -[Largest contributing segment or broad-based note] - - -[Side-by-side comparison of bad vs stable segments] -[3-5 discriminative differences with numbers] - - -[1-3 ranked hypotheses] -Hypothesis: -Evidence so far: -Prediction: -Test: -Confirm if: -Refute if: -Owner/next action: - -[Immediate mitigations, next data pulls, experiments/rollbacks] - - -FAILURE -- Any required subproblem section is missing or out of sequence. -- Output lacks methods/decision rules/findings/next-step per subproblem. -- No driver decomposition or no impact-ranked segmentation. -- Hypotheses are not testable (missing confirm/refute criteria). -- Claims are generic or not grounded in provided inputs. -- Assumptions or confidence labels are missing. -- Required schema is malformed or incomplete. diff --git a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml b/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml deleted file mode 100644 index fb619773..00000000 --- a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Metric drops diagnosis with rigorous stepwise decomposition" - short_description: "Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a product workflow for business..." - brand_color: "#0F766E" - default_prompt: "Use $metric-drops-diagnosis-with-rigorous-stepwise-decomposition with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/productize.json b/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/productize.json deleted file mode 100644 index f9014556..00000000 --- a/skills/metric-drops-diagnosis-with-rigorous-stepwise-decomposition/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Metric drops diagnosis with rigorous stepwise decomposition", - "category": "Analytics", - "lifecycle": "Strategize", - "tags": [ - "metric-drops-diagnosis-with-rigorous-stepwise-decomposition", - "metric", - "drops", - "diagnosis", - "rigorous", - "stepwise", - "decomposition" - ], - "use_when": "Metric drops diagnosis with rigorous stepwise decomposition. Use when the user needs a product workflow for business analysis related to metric drops diagnosis with rigorous stepwise decomposition. Trigger terms: pm, business-analysis, analytics, metrics, diagnosis.", - "do_not_use_when": "Do not use Metric drops diagnosis with rigorous stepwise decomposition when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "metric-drops-diagnosis-with-rigorous-stepwise-decomposition", - "metric", - "drops", - "diagnosis", - "rigorous", - "stepwise", - "decomposition" - ], - "framework_fit": "Metric drops diagnosis with rigorous stepwise decomposition fits Analytics work in the Strategize lifecycle when the user needs Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Metric drops diagnosis with rigorous stepwise decomposition as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Metric drops diagnosis with rigorous stepwise decomposition when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $metric-drops-diagnosis-with-rigorous-stepwise-decomposition to turn this metric context into a decision-ready Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Metric drops diagnosis with rigorous stepwise decomposition strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/metrics-review/SKILL.md b/skills/metrics-review/SKILL.md deleted file mode 100644 index 2f23b171..00000000 --- a/skills/metrics-review/SKILL.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -name: metrics-review -description: >- - Review and analyze product metrics with trend analysis and actionable insights. Use when - running a weekly, monthly, or quarterly metrics review, investigating a spike or drop, - comparing against targets, or turning raw numbers into a scorecard with recommended actions. ---- - - - -# Metrics Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `metrics-review` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Metric scorecard, trend diagnosis, and recommended action plan - -Review product metrics, identify trends, and surface action-oriented insights. - -## Argument Hint - -`
` | Type-scoped runtime overrides applied after `[defaults]` for `productize tasks run` | + +#### `[[tasks.run.task_runtime_rules]]` + +Per-task runtime rules let `productize tasks run` change the runtime for tasks that match a given task `type`. This v1 config surface is intentionally bulk-oriented: config supports `type` selectors only, while one-off task `id` overrides are available from the CLI for the current run. + +| Field | Type | Description | +| --- | --- | --- | +| `type` | string | Task type selector such as `frontend`, `backend`, or any custom type from `[tasks].types` | +| `ide` | string | Runtime override for matching tasks | +| `model` | string | Model override for matching tasks | +| `reasoning_effort` | string | Reasoning effort override: `low`, `medium`, `high`, `xhigh` | + +Rules are applied in declaration order within config, with later rules for the same `type` replacing earlier ones when workspace and global config are merged. At execution time, the effective precedence is: + +1. Base runtime from `[defaults]` and `[tasks.run]` +2. Config `[[tasks.run.task_runtime_rules]]` matching the task `type` +3. CLI `--task-runtime type=...` rules for the current run +4. CLI `--task-runtime id=...` rules for the current run + +Example: + +```toml +[defaults] +ide = "codex" +model = "gpt-5.5" +reasoning_effort = "medium" + +[[tasks.run.task_runtime_rules]] +type = "frontend" +model = "gpt-5.5" +reasoning_effort = "high" + +[[tasks.run.task_runtime_rules]] +type = "docs" +ide = "claude" +model = "opus" +``` + +### `[tasks]` + +Task type registry. + +| Field | Type | Description | +| --- | --- | --- | +| `types` | string[] | Allowed task types. Default: `["frontend", "backend", "docs", "test", "infra", "refactor", "chore", "bugfix"]` | + +### `[fix_reviews]` + +Options specific to `productize reviews fix`. + +| Field | Type | Description | +| --- | --- | --- | +| `concurrent` | int | Number of batches to process in parallel (1-10) | +| `batch_size` | int | Number of file groups per batch (1-50) | +| `include_resolved` | bool | Include already-resolved review issues | + +### `[fetch_reviews]` + +Options specific to `productize reviews fetch`. + +| Field | Type | Description | +| --- | --- | --- | +| `provider` | string | Default review provider (e.g., `coderabbit`) | +| `nitpicks` | bool | Enable or disable CodeRabbit review-body comments (`nitpick`, `minor`, and `major`). Default is enabled when unset | + +### `[watch_reviews]` + +Options specific to `productize reviews watch`. Watch-specific loop values come from this section; child review +fetch/fix defaults continue to come from `[fetch_reviews]`, `[fix_reviews]`, and `[defaults]`. + +| Field | Type | Description | +| --- | --- | --- | +| `max_rounds` | int | Maximum watch rounds. Must be greater than zero when `until_clean = true`. | +| `poll_interval` | string | Positive Go duration between provider status checks (e.g., `30s`). | +| `review_timeout` | string | Positive Go duration to wait for the provider to review a PR head (e.g., `30m`). | +| `quiet_period` | string | Positive Go duration to wait after the latest provider review/status signal before fetching issues. | +| `auto_push` | bool | Push committed fixes after each successful round. Requires `defaults.auto_commit = true` when enabled from config. | +| `until_clean` | bool | Continue until the provider has reviewed the current PR head and no actionable issues are fetched. | +| `push_remote` | string | Optional push remote. Must be set together with `push_branch`; omit both to resolve upstream later. | +| `push_branch` | string | Optional push branch. Must be set together with `push_remote`; omit both to resolve upstream later. | + +CLI usage: + +```bash +productize reviews watch --provider coderabbit --pr 123 +productize reviews watch my-workflow --provider coderabbit --pr 123 --max-rounds 4 +productize reviews watch my-workflow --provider coderabbit --pr 123 --auto-push --push-remote origin --push-branch feature/reviews +``` + +Watch runs are daemon-owned parent runs. They wait until the provider reports a completed, settled review for the +current PR head, fetch actionable issues, launch child `reviews fix` runs, optionally push the child commit, then +repeat until the provider-current fetch is clean or `max_rounds` is reached. For CodeRabbit, settled means the latest +CodeRabbit commit status for the PR head is complete; transient "review in progress" statuses keep the watch waiting. + +Auto-push safety: + +- `auto_push = true` requires committed fixes. The watch parent forces child `auto_commit = true`; an explicit + `runtime_overrides.auto_commit = false` is rejected. +- The daemon never restores, resets, cleans, or manually stages unrelated work. It inspects git state and runs only + `git push HEAD:` for committed branch state. It pushes after a child fix run completed, all fetched + issues are resolved, and `HEAD` advanced; when `auto_push` starts with existing unpushed commits, it first pushes + that committed `HEAD` so the provider can review the same head the watch is waiting on. +- `push_remote` and `push_branch` can be supplied by config/CLI or resolved from the current upstream. Missing push + target information fails before pushing. + +Lifecycle events emitted by the parent run: + +| Event | Purpose | +| --- | --- | +| `review.watch_started` | Initial provider/PR/workflow/git state, including `head_sha`, `remote`, `branch`, `dirty`, and `unpushed_commits`. | +| `review.watch_waiting` | Provider has not yet reviewed the current PR head; includes `status`, `review_id`, and `review_state` when available. | +| `review.watch_round_fetched` | A provider-current round produced actionable issues; includes `round`, `total`, `resolved`, and `unresolved`. | +| `review.watch_fix_started` | Child `reviews fix` run started; includes `child_run_id`. | +| `review.watch_fix_completed` | Child run reached a terminal state; includes `status` and `error` when failed. | +| `review.watch_push_started` / `review.watch_push_completed` / `review.watch_push_failed` | Auto-push lifecycle with `head_sha`, `remote`, `branch`, and `error` on failure. Startup reconciliation uses `round = 0`. | +| `review.watch_clean` | Provider-current fetch returned no actionable issues. | +| `review.watch_max_rounds` | The parent stopped because `max_rounds` was reached before a clean result. | + +Extension hooks exposed to Go and TypeScript SDKs: + +| Hook | Mutable | Payload highlights | Allowed patch fields | +| --- | --- | --- | --- | +| `review.watch_pre_round` | yes | `run_id`, `provider`, `pr`, `workflow`, `round`, `head_sha`, `review_id`, `review_state`, `status`, `nitpicks`, `runtime_overrides`, `batching`, `continue` | `nitpicks`, `runtime_overrides`, `batching`, `continue`, `stop_reason` | +| `review.watch_post_round` | no | `run_id`, `provider`, `pr`, `workflow`, `round`, `child_run_id`, `status`, `total`, `resolved`, `unresolved`, `pushed`, `stop_reason`, `error` | none | +| `review.watch_pre_push` | yes | `run_id`, `provider`, `pr`, `workflow`, `round`, `head_sha`, `remote`, `branch`, `push` (`round = 0` for startup reconciliation) | `remote`, `branch`, `push`, `stop_reason` | +| `review.watch_finished` | no | `run_id`, `child_run_id`, `provider`, `pr`, `workflow`, `round`, `head_sha`, `status`, `terminal_reason`, `stopped`, `clean`, `max_rounds`, `error` | none | + +Hooks may veto a round or push only by returning `continue = false` or `push = false` with a non-empty +`stop_reason`. Hooks cannot mark a PR clean, skip provider-current detection, or mutate immutable provider/head/status +fields. + +### `[exec]` + +Options specific to `productize exec`. Inherits all `[defaults]` fields plus: + +| Field | Type | Description | +| --- | --- | --- | +| `verbose` | bool | Emit operational runtime logs to stderr | +| `persist` | bool | Save artifacts under `~/.productize/runs//` | + +### `[sound]` + +Optional audio notifications that play when a run reaches a terminal state. Applies to both `productize tasks run` and `productize exec`. Disabled by default โ€” setting any field without `enabled = true` is a no-op. + +| Field | Type | Description | +| --- | --- | --- | +| `enabled` | bool | Master switch. Default `false`. | +| `on_completed` | string | Preset name or absolute path played on `run.completed`. Default `glass` when `enabled = true`. | +| `on_failed` | string | Preset name or absolute path played on `run.failed` and `run.cancelled`. Default `basso` when `enabled = true`. | + +**Presets** (resolve to platform-native files at play time): + +| Preset | macOS | Linux (freedesktop) | Windows | +| --- | --- | --- | --- | +| `glass` | `/System/Library/Sounds/Glass.aiff` | `complete.oga` | `tada.wav` | +| `basso` | `/System/Library/Sounds/Basso.aiff` | `dialog-error.oga` | `chord.wav` | +| `ping` | `Ping.aiff` | `message.oga` | `ding.wav` | +| `hero` | `Hero.aiff` | `complete.oga` | `tada.wav` | +| `funk` | `Funk.aiff` | `bell.oga` | `notify.wav` | +| `tink` | `Tink.aiff` | `message.oga` | `chimes.wav` | +| `submarine` | `Submarine.aiff` | `bell.oga` | `Ring01.wav` | + +**Absolute paths** bypass preset lookup, so any local sound file works: + +```toml +[sound] +enabled = true +on_completed = "/System/Library/Sounds/Hero.aiff" +on_failed = "/Users/me/sounds/custom-fail.wav" +``` + +**Platform requirements**: `afplay` (bundled with macOS), `paplay` (Linux, from `pulseaudio-utils`), or `powershell` + `System.Media.SoundPlayer` (Windows). On unix variants without one of these tools the feature silently falls back to no-op; playback errors never break a run. + +## Complete Example + +```toml +[defaults] +ide = "claude" +model = "opus" +reasoning_effort = "high" +auto_commit = true +add_dirs = ["../shared-lib", "../docs"] +timeout = "45m" +max_retries = 2 +retry_backoff_multiplier = 1.5 + +[tasks] +types = ["frontend", "backend", "docs", "test", "infra", "refactor", "chore", "bugfix"] + +[tasks.run] +include_completed = false + +[fix_reviews] +concurrent = 2 +batch_size = 3 +include_resolved = false + +[fetch_reviews] +provider = "coderabbit" +nitpicks = false + +[watch_reviews] +until_clean = true +max_rounds = 6 +poll_interval = "30s" +review_timeout = "30m" +quiet_period = "20s" +auto_push = false + +[exec] +verbose = false +persist = false + +[sound] +enabled = true +on_completed = "glass" +on_failed = "basso" +``` diff --git a/skills/productize-runtime/references/skills-reference.md b/skills/productize-runtime/references/skills-reference.md new file mode 100644 index 00000000..e3d1e748 --- /dev/null +++ b/skills/productize-runtime/references/skills-reference.md @@ -0,0 +1,178 @@ +# Bundled Skills Reference + +Detailed catalog of bundled Productize workflow skills plus the bundled Productize +skill layer. + +--- + +## idea-forge + +**Trigger:** `/idea-forge [feature-idea]` + +Install first: `productize ext install --yes itseffi/productize --remote github --ref --subdir extensions/idea-forge` -> `productize ext enable idea-forge` -> `productize setup` + +Expands a raw feature idea into a structured, research-backed specification through interactive brainstorming, web research, business analysis, and multi-advisor debate. + +- **Inputs:** Feature idea or problem description. Optional existing `_idea.md` for update mode. +- **Outputs:** `.productize/tasks//_idea.md`, ADRs in `adrs/`. +- **Pipeline position:** Optional first step. Feeds into `create-prd`. +- **Process:** Clarifying questions -> parallel codebase + web research -> business viability analysis -> advisor debate -> opportunity scan -> draft -> user approval. +- **Use when:** The user has a raw idea and wants to explore viability before committing to a PRD. +- **Do not use for:** PRD creation, technical specifications, task breakdown, or code implementation. + +--- + +## create-prd + +**Trigger:** `/create-prd [feature-name-or-idea] [idea-file]` + +Creates a business-focused Product Requirements Document through structured brainstorming with parallel codebase and web research. + +- **Inputs:** Feature name or idea. Optional existing `_idea.md` or `_prd.md` for update mode. +- **Outputs:** `.productize/tasks//_prd.md`, ADRs in `adrs/`. +- **Pipeline position:** After ideation (optional). Feeds into `create-techspec`. +- **Process:** Context discovery (codebase + web) -> clarifying questions -> 2-3 product approaches -> ADR for chosen approach -> draft PRD -> user approval. +- **Use when:** Starting a new feature or product, building or updating a PRD. +- **Do not use for:** Technical specifications, task breakdowns, or code implementation. + +--- + +## create-techspec + +**Trigger:** `/create-techspec [feature-name]` + +Translates PRD business requirements into a technical implementation design. + +- **Inputs:** Existing `_prd.md` from the previous stage. +- **Outputs:** `.productize/tasks//_techspec.md`, ADRs in `adrs/`. +- **Pipeline position:** After PRD. Feeds into `create-tasks`. +- **Process:** Codebase architecture exploration -> technical questions -> technical ADRs -> TechSpec draft -> user approval. +- **Use when:** A PRD exists and needs a technical implementation plan. +- **Do not use for:** PRD creation, task execution, or code implementation. + +--- + +## create-tasks + +**Trigger:** `/create-tasks [feature-name]` + +Decomposes PRDs and TechSpecs into detailed, independently implementable task files with codebase-informed enrichment. + +- **Inputs:** Existing `_prd.md` and `_techspec.md`. +- **Outputs:** Individual task files (`task_01.md`, `task_02.md`, etc.), `_tasks.md` master list. +- **Pipeline position:** After TechSpec. Feeds into `productize tasks run`. +- **Process:** Load PRD+TechSpec context -> break into granular tasks -> user approval -> generate task files -> enrich with codebase patterns -> validate with `productize tasks validate`. +- **Task metadata:** Each task has YAML frontmatter with `status` (pending/in_progress/completed), `title`, `type`, `complexity`, and `dependencies`. +- **Use when:** A PRD and TechSpec exist and need to be broken into executable tasks. +- **Do not use for:** Execution, review, or code implementation. + +--- + +## execute-task + +**Trigger:** Internal (called by `productize tasks run`). Do not invoke directly. + +Executes one PRD task end-to-end using the provided task file, PRD directory, and tracking file paths. + +- **Inputs:** Task specification, PRD directory path, task file path, master tasks file path, auto-commit mode. Optional workflow memory paths. +- **Outputs:** Implemented code changes, updated task tracking files, optional commit. +- **Pipeline position:** Called by `productize tasks run` for each task in sequence. +- **Process:** Ground in PRD/TechSpec context -> build execution checklist -> implement -> validate with `final-verify` -> update tracking -> optional commit. +- **Use when:** Invoked internally by the execution pipeline. +- **Do not use for:** Direct invocation, PR review batches, or standalone verification. + +--- + +## review-round + +**Trigger:** `/review-round [feature-name]` + +Performs a comprehensive code review of a PRD implementation and generates review issue files. + +- **Inputs:** Feature name identifying the workflow under `.productize/tasks//`. +- **Outputs:** Review round directory `reviews-NNN/` with `issue_*.md` files containing round metadata in YAML frontmatter. +- **Pipeline position:** After execution. Outputs feed into `fix-reviews`. +- **Use when:** Reviewing implemented PRD tasks without an external review provider. +- **Do not use for:** Fetching external reviews (use `productize reviews fetch`), fixing issues (use `productize reviews fix`). + +--- + +## fix-reviews + +**Trigger:** Internal (called by `productize reviews fix`). Do not invoke directly. + +Executes provider-agnostic PR review remediation using existing review round files. + +- **Inputs:** Scoped issue files from the review round and their YAML frontmatter. +- **Outputs:** Updated issue files with triage and status, code fixes, verification evidence. +- **Pipeline position:** Called by `productize reviews fix`. Operates on output from `review-round` or `productize reviews fetch`. +- **Process:** Read round context -> triage issues (valid/invalid) -> fix valid issues in severity order -> verify with `final-verify` -> close out issue files. +- **Use when:** Invoked internally by the review remediation pipeline. +- **Do not use for:** Fetching reviews, PRD task execution, or generic coding. + +--- + +## final-verify + +**Trigger:** `/final-verify` + +Enforces fresh verification evidence before any completion, fix, or passing claim, and before commits or PR creation. + +- **Inputs:** None. Operates on the current workspace state. +- **Outputs:** Verification Report with claim, command, exit code, output summary, and verdict. +- **Pipeline position:** Used at the end of `execute-task`, `fix-reviews`, and any completion claim. +- **Core principle:** Evidence before claims, always. No completion claims without fresh verification evidence. +- **Process:** Identify verification command -> execute full command -> read complete output -> verify exit code and counts -> report with evidence. +- **Use when:** About to report success, hand off work, commit code, or create a PR. +- **Do not use for:** Early planning, brainstorming, or tasks not yet at a verification step. + +--- + +## workflow-memory + +**Trigger:** Internal (called by `execute-task`). Do not invoke directly. + +Maintains workflow-scoped task memory for Productize runs using files under `.productize/tasks//memory/`. + +- **Inputs:** Workflow memory directory path, shared memory file path, current task memory file path. +- **Outputs:** Updated `MEMORY.md` (shared) and per-task memory files. +- **Pipeline position:** Used during task execution to maintain cross-task context. +- **Two-tier memory:** Shared workflow memory (`MEMORY.md`) for cross-task decisions and risks. Per-task memory for task-local operational details. +- **Promotion test:** Items promoted from task to shared memory only when needed by other tasks, durable across runs, and not derivable from existing artifacts. +- **Use when:** Task execution requires reading or updating workflow memory. +- **Do not use for:** PR review remediation, global user preferences, or event-log summarization. + +--- + +## productize + +**Trigger:** `/productize` + +This skill. Explains Productize capabilities, CLI commands, core workflow skills, optional extension skills, configuration, artifact structure, reusable agents, and extensions. + +- **Inputs:** None. +- **Outputs:** Reference information presented to the agent. +- **Pipeline position:** Standalone reference, not part of the pipeline. +- **Use when:** The user asks how to use Productize, what commands are available, or how the workflow works. +- **Do not use for:** Executing any workflow step. Use the specific workflow skills (`create-prd`, `create-techspec`, `create-tasks`, `execute-task`, `review-round`, `fix-reviews`, `final-verify`, `workflow-memory`) instead. + +--- + +## Productize Skill Layer + +Productize skills are bundled on top of the Productize workflow skills. They keep +their namespaced triggers so they do not replace or collide with Productize's +core workflow skills. + +- **Router:** `/productize` +- **0-1 build loop:** `/productize-0-1` +- **Core gates:** `/productize-thesis-review`, `/productize-product-review`, + `/productize-design-review`, `/productize-eng-review`, `/productize-qa`, + `/productize-release`, `/productize-docs`, `/productize-dx-review`, + `/productize-comms-review` +- **Routed catalog:** strategy, discovery, growth, analytics, finance, delivery, + design, marketing, operations, stakeholder communication, business model, + venture, and AI-execution skills. + +Use `/productize` when the Productize route is unclear. Use a specific +`/productize-*` skill when the product job is already known. diff --git a/skills/productize-runtime/references/workflow-guide.md b/skills/productize-runtime/references/workflow-guide.md new file mode 100644 index 00000000..552d50e8 --- /dev/null +++ b/skills/productize-runtime/references/workflow-guide.md @@ -0,0 +1,161 @@ +# Workflow Guide + +End-to-end walkthrough of the Productize development pipeline from setup through archive. + +## Prerequisites + +1. **Install Productize.** Ensure the `productize` binary is available in the system PATH. +2. **Run setup.** Execute `productize setup` to install core skills into target agents plus setup assets from enabled extensions. For a quick start: `productize setup --all`. +3. **Install optional ideation extension when needed.** To use `/idea-forge`, run `productize ext install --yes itseffi/productize --remote github --ref --subdir extensions/idea-forge`, then `productize ext enable idea-forge`, then `productize setup` again. +4. **Configure workspace (optional).** Create `.productize/config.toml` to set default IDE, model, and other preferences. Read `config-reference.md` for all fields. + +## Phase 1: Ideation (Optional) + +**Skill:** `/idea-forge [feature-idea]` + +Use when a raw idea needs structured exploration before committing to a PRD. + +Install flow: `productize ext install --yes itseffi/productize --remote github --ref --subdir extensions/idea-forge` -> `productize ext enable idea-forge` -> `productize setup` + +1. Invoke `/idea-forge` inside an agent session with the feature idea. +2. Answer 3-6 clarifying questions (one per message, multiple-choice preferred). +3. The skill runs parallel codebase exploration and web research. +4. A business analyst persona evaluates viability with KPIs and scoring. +5. A advisor debate (3-5 advisors from the extension-shipped advisor agents) challenges scope and surfaces risks. +6. A product strategist scans for higher-leverage alternatives. +7. Review and approve the draft idea spec. +8. Output: `.productize/tasks//_idea.md` + ADRs. + +**Skip when:** The requirements are already well-understood and a PRD can be written directly. + +## Phase 2: Requirements + +**Skill:** `/create-prd [feature-name-or-idea] [idea-file]` + +1. Invoke `/create-prd` with the feature name. If `_idea.md` exists, it is used as primary context. +2. The skill runs parallel codebase and market research. +3. Answer clarifying questions focused on WHAT and WHY (not HOW). +4. Choose from 2-3 product approaches. An ADR is created for the decision. +5. Review and approve the complete PRD draft. +6. Output: `.productize/tasks//_prd.md` + ADRs. + +**Key rule:** The PRD describes user capabilities and business outcomes only. No databases, APIs, frameworks, or architecture. + +## Phase 3: Technical Design + +**Skill:** `/create-techspec [feature-name]` + +1. Invoke `/create-techspec` with the feature name. +2. The skill reads the existing `_prd.md` and explores the codebase architecture. +3. Answer technical clarifying questions. +4. Technical ADRs are created for architecture decisions. +5. Review and approve the TechSpec draft. +6. Output: `.productize/tasks//_techspec.md` + ADRs. + +**Contains:** System architecture, data models, core interfaces, API design, development sequencing. + +## Phase 4: Task Decomposition + +**Skill:** `/create-tasks [feature-name]` + +1. Invoke `/create-tasks` with the feature name. +2. The skill loads the PRD and TechSpec, then breaks them into granular tasks. +3. Review the proposed task breakdown. +4. Task files are generated with YAML frontmatter: `status`, `title`, `type`, `complexity`, `dependencies`. +5. Tasks are enriched with codebase patterns and implementation context. +6. Validation runs via `productize tasks validate`. +7. Output: `task_01.md` through `task_N.md`, `_tasks.md` master list. + +**Task types:** `frontend`, `backend`, `docs`, `test`, `infra`, `refactor`, `chore`, `bugfix`. Custom types can be registered in `.productize/config.toml` under `[tasks].types`. + +## Phase 5: Execution + +**Command:** `productize tasks run --ide ` + +1. Productize reads task files from `.productize/tasks//` in order, respecting dependencies. +2. The CLI auto-starts the home-scoped daemon when needed and starts the run through daemon transport. +3. For each pending task, Productize constructs a prompt including the task spec, PRD, TechSpec, ADRs, and workflow memory. +4. The configured ACP runtime executes the task using the `execute-task` skill. +5. Each task: read spec -> implement -> validate with `final-verify` -> update tracking -> optional commit. +6. Workflow memory is maintained across tasks via `workflow-memory`. + +**Key flags:** +- `--auto-commit` -- create a local commit after each task completes cleanly. +- `--dry-run` -- generate prompts without running the IDE tool. +- `--include-completed` -- re-process tasks already marked as completed. + +**Attach mode:** In interactive terminals, `tasks run` streams textual run observation by default; use `--stream`, `--detach`, or `--attach` to control whether the command follows the run or returns immediately. + +## Phase 6: Review + +Two paths are available: + +### Path A: Manual AI Review + +**Skill:** `/review-round [feature-name]` + +Invoke inside an agent session. The skill performs a comprehensive code review of the implementation and generates issue files under `.productize/tasks//reviews-NNN/`. + +### Path B: External Provider Review + +**Command:** `productize reviews fetch --provider coderabbit --pr ` + +Fetches review comments from an external provider (currently CodeRabbit) and writes them as issue markdown files under `reviews-NNN/`. + +**Both paths produce:** `issue_*.md` files with YAML frontmatter containing round metadata (`provider`, `pr`, `round`, `round_created_at`) plus issue metadata (`status`, `severity`, `file`, `line`). + +## Phase 7: Remediation + +**Command:** `productize reviews fix --ide ` + +1. Productize reads issue files from the latest (or specified) review round. +2. For each batch of issues, the configured ACP runtime executes the `fix-reviews` skill. +3. Each issue is triaged (valid/invalid), fixed if valid (in severity order), and verified with `final-verify`. +4. Issue file frontmatter is updated: `pending` -> `valid`/`invalid` -> `resolved`. + +**Key flags:** +- `--concurrent ` -- process N batches in parallel. +- `--batch-size ` -- group N file scopes per batch. +- `--include-resolved` -- re-process already-resolved issues. + +**Iterate:** Repeat phases 6-7 until all reviews are clean, then merge. + +## Phase 8: Archive + +**Command:** `productize archive --name ` + +Moves fully completed workflows from `.productize/tasks//` to `.productize/tasks/_archived/-/`. + +**Eligibility:** Run `productize sync` first. Archive eligibility is computed from synced daemon state: all task items must be completed and all synced review issues must be resolved. + +## Ad Hoc Execution + +**Command:** `productize exec [prompt]` + +Execute a single prompt outside the pipeline workflow. + +- **Reusable agents:** `productize exec --agent reviewer "Review the staged changes"` invokes a named agent. +- **Persistence:** `--persist` saves session artifacts. Resume with `--run-id `. +- **Output formats:** `--format text` (default), `json` (lean JSONL), `raw-json` (full event stream). + +## Workflow Memory + +The `workflow-memory` skill maintains two tiers of context during task execution: + +| File | Purpose | +| --- | --- | +| `.productize/tasks//memory/MEMORY.md` | Shared cross-task memory: architecture decisions, discovered patterns, open risks, handoffs | +| `.productize/tasks//memory/task_NN.md` | Per-task memory: objective snapshot, files touched, errors hit, next steps | + +- Memory files are scaffolded before task execution and updated during the run. +- Agents read both files as mandatory context before editing code. +- Promotion from task to shared memory requires: needed by other tasks, durable across runs, and not derivable from existing artifacts. +- Auto-compaction triggers when files exceed size limits. + +## Architecture Decision Records + +ADRs are created during ideation, PRD, and TechSpec phases to document significant decisions. + +- **Location:** `.productize/tasks//adrs/adr-NNN.md` (zero-padded 3-digit numbers). +- **Structure:** Status, Date, Context, Decision, Alternatives Considered, Consequences. +- **Referenced by:** PRDs, TechSpecs, and idea specs include an "Architecture Decision Records" section linking to all ADRs. diff --git a/.agents/skills/productize-scope-defense-using-time-cost-tradeoff-analysis/SKILL.md b/skills/productize-scope-defense-using-time-cost-tradeoff-analysis/SKILL.md similarity index 100% rename from .agents/skills/productize-scope-defense-using-time-cost-tradeoff-analysis/SKILL.md rename to skills/productize-scope-defense-using-time-cost-tradeoff-analysis/SKILL.md diff --git a/.agents/skills/productize-scope-defense-using-time-cost-tradeoff-analysis/agents/openai.yaml b/skills/productize-scope-defense-using-time-cost-tradeoff-analysis/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-scope-defense-using-time-cost-tradeoff-analysis/agents/openai.yaml rename to skills/productize-scope-defense-using-time-cost-tradeoff-analysis/agents/openai.yaml diff --git a/.agents/skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md b/skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md similarity index 100% rename from .agents/skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md rename to skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md diff --git a/.agents/skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/agents/openai.yaml b/skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/agents/openai.yaml rename to skills/productize-sketch-descriptions-for-wireframes-from-product-ideas/agents/openai.yaml diff --git a/.agents/skills/productize-skimmable-writing-transformation/SKILL.md b/skills/productize-skimmable-writing-transformation/SKILL.md similarity index 100% rename from .agents/skills/productize-skimmable-writing-transformation/SKILL.md rename to skills/productize-skimmable-writing-transformation/SKILL.md diff --git a/.agents/skills/productize-skimmable-writing-transformation/agents/openai.yaml b/skills/productize-skimmable-writing-transformation/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-skimmable-writing-transformation/agents/openai.yaml rename to skills/productize-skimmable-writing-transformation/agents/openai.yaml diff --git a/.agents/skills/productize-slide-decks-from-problem-statements-and-context/SKILL.md b/skills/productize-slide-decks-from-problem-statements-and-context/SKILL.md similarity index 100% rename from .agents/skills/productize-slide-decks-from-problem-statements-and-context/SKILL.md rename to skills/productize-slide-decks-from-problem-statements-and-context/SKILL.md diff --git a/.agents/skills/productize-slide-decks-from-problem-statements-and-context/agents/openai.yaml b/skills/productize-slide-decks-from-problem-statements-and-context/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-slide-decks-from-problem-statements-and-context/agents/openai.yaml rename to skills/productize-slide-decks-from-problem-statements-and-context/agents/openai.yaml diff --git a/.agents/skills/productize-solution-anti-patterns-from-customer-problem-analysis/SKILL.md b/skills/productize-solution-anti-patterns-from-customer-problem-analysis/SKILL.md similarity index 100% rename from .agents/skills/productize-solution-anti-patterns-from-customer-problem-analysis/SKILL.md rename to skills/productize-solution-anti-patterns-from-customer-problem-analysis/SKILL.md diff --git a/.agents/skills/productize-solution-anti-patterns-from-customer-problem-analysis/agents/openai.yaml b/skills/productize-solution-anti-patterns-from-customer-problem-analysis/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-solution-anti-patterns-from-customer-problem-analysis/agents/openai.yaml rename to skills/productize-solution-anti-patterns-from-customer-problem-analysis/agents/openai.yaml diff --git a/.agents/skills/productize-solution-design-for-edge-cases-in-product-development/SKILL.md b/skills/productize-solution-design-for-edge-cases-in-product-development/SKILL.md similarity index 100% rename from .agents/skills/productize-solution-design-for-edge-cases-in-product-development/SKILL.md rename to skills/productize-solution-design-for-edge-cases-in-product-development/SKILL.md diff --git a/.agents/skills/productize-solution-design-for-edge-cases-in-product-development/agents/openai.yaml b/skills/productize-solution-design-for-edge-cases-in-product-development/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-solution-design-for-edge-cases-in-product-development/agents/openai.yaml rename to skills/productize-solution-design-for-edge-cases-in-product-development/agents/openai.yaml diff --git a/.agents/skills/productize-spec-writing/SKILL.md b/skills/productize-spec-writing/SKILL.md similarity index 100% rename from .agents/skills/productize-spec-writing/SKILL.md rename to skills/productize-spec-writing/SKILL.md diff --git a/.agents/skills/productize-spec-writing/agents/openai.yaml b/skills/productize-spec-writing/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-spec-writing/agents/openai.yaml rename to skills/productize-spec-writing/agents/openai.yaml diff --git a/.agents/skills/productize-sprint-planning/SKILL.md b/skills/productize-sprint-planning/SKILL.md similarity index 100% rename from .agents/skills/productize-sprint-planning/SKILL.md rename to skills/productize-sprint-planning/SKILL.md diff --git a/.agents/skills/productize-sprint-planning/agents/openai.yaml b/skills/productize-sprint-planning/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-sprint-planning/agents/openai.yaml rename to skills/productize-sprint-planning/agents/openai.yaml diff --git a/.agents/skills/productize-sql-queries/SKILL.md b/skills/productize-sql-queries/SKILL.md similarity index 100% rename from .agents/skills/productize-sql-queries/SKILL.md rename to skills/productize-sql-queries/SKILL.md diff --git a/.agents/skills/productize-sql-queries/agents/openai.yaml b/skills/productize-sql-queries/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-sql-queries/agents/openai.yaml rename to skills/productize-sql-queries/agents/openai.yaml diff --git a/.agents/skills/productize-sql-query-from-requirements-and-data-tables/SKILL.md b/skills/productize-sql-query-from-requirements-and-data-tables/SKILL.md similarity index 100% rename from .agents/skills/productize-sql-query-from-requirements-and-data-tables/SKILL.md rename to skills/productize-sql-query-from-requirements-and-data-tables/SKILL.md diff --git a/.agents/skills/productize-sql-query-from-requirements-and-data-tables/agents/openai.yaml b/skills/productize-sql-query-from-requirements-and-data-tables/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-sql-query-from-requirements-and-data-tables/agents/openai.yaml rename to skills/productize-sql-query-from-requirements-and-data-tables/agents/openai.yaml diff --git a/.agents/skills/productize-stakeholder-brief-clarification-and-problem-definition/SKILL.md b/skills/productize-stakeholder-brief-clarification-and-problem-definition/SKILL.md similarity index 100% rename from .agents/skills/productize-stakeholder-brief-clarification-and-problem-definition/SKILL.md rename to skills/productize-stakeholder-brief-clarification-and-problem-definition/SKILL.md diff --git a/.agents/skills/productize-stakeholder-brief-clarification-and-problem-definition/agents/openai.yaml b/skills/productize-stakeholder-brief-clarification-and-problem-definition/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-stakeholder-brief-clarification-and-problem-definition/agents/openai.yaml rename to skills/productize-stakeholder-brief-clarification-and-problem-definition/agents/openai.yaml diff --git a/.agents/skills/productize-stakeholder-decision-making-using-toc-thinking-process/SKILL.md b/skills/productize-stakeholder-decision-making-using-toc-thinking-process/SKILL.md similarity index 100% rename from .agents/skills/productize-stakeholder-decision-making-using-toc-thinking-process/SKILL.md rename to skills/productize-stakeholder-decision-making-using-toc-thinking-process/SKILL.md diff --git a/.agents/skills/productize-stakeholder-decision-making-using-toc-thinking-process/agents/openai.yaml b/skills/productize-stakeholder-decision-making-using-toc-thinking-process/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-stakeholder-decision-making-using-toc-thinking-process/agents/openai.yaml rename to skills/productize-stakeholder-decision-making-using-toc-thinking-process/agents/openai.yaml diff --git a/.agents/skills/productize-stakeholder-moo-objections-and-product-derailment-risks/SKILL.md b/skills/productize-stakeholder-moo-objections-and-product-derailment-risks/SKILL.md similarity index 100% rename from .agents/skills/productize-stakeholder-moo-objections-and-product-derailment-risks/SKILL.md rename to skills/productize-stakeholder-moo-objections-and-product-derailment-risks/SKILL.md diff --git a/.agents/skills/productize-stakeholder-moo-objections-and-product-derailment-risks/agents/openai.yaml b/skills/productize-stakeholder-moo-objections-and-product-derailment-risks/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-stakeholder-moo-objections-and-product-derailment-risks/agents/openai.yaml rename to skills/productize-stakeholder-moo-objections-and-product-derailment-risks/agents/openai.yaml diff --git a/skills/productize-stakeholder-power-interest-and-influence-map/SKILL.md b/skills/productize-stakeholder-power-interest-and-influence-map/SKILL.md new file mode 100644 index 00000000..41ea4358 --- /dev/null +++ b/skills/productize-stakeholder-power-interest-and-influence-map/SKILL.md @@ -0,0 +1,168 @@ +--- +name: productize-stakeholder-power-interest-and-influence-map +description: >- + Stakeholder Powerโ€“Interest & Influence Map. Use when the user needs a product workflow for + stakeholder management related to stakeholder powerโ€“interest & influence map. Trigger terms: + stakeholder-management, influence, internal-politics, communication. +--- + + + +# Stakeholder Powerโ€“Interest & Influence Map + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `stakeholder-power-interest-and-influence-map` +- **Lifecycle**: Align +- **Category**: Decision Making +- **Primary artifact**: Stakeholder decision influence map with power-interest matrix, influence pyramid, role identity risks, engagement plan, and mitigations + +Use this skill to run the Productize prompt contract for **Stakeholder Powerโ€“Interest & Influence Map**. + +## Instructions + +1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. +2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. +3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. +4. Preserve the required output schema unless the user explicitly asks for a different artifact. +5. Keep claims grounded in the provided inputs and disclose gaps. + +## Prompt Contract + +INPUTS + +- [No explicit variables declared; use provided context.] + + +GOAL +Produce a high-quality deliverable for: "Stakeholder Powerโ€“Interest & Influence Map". +Success metric: +- Completes all required tasks and decision logic from the prompt instructions. +- Output is specific, evidence-based, and actionable. +- Output follows the required structure exactly. + +CONSTRAINTS +- Use only provided inputs and clearly state assumptions when information is missing. +- Do not skip required analysis steps, sections, or validation logic. +- Keep recommendations/outputs grounded in the input context; avoid generic filler. +- Build a stakeholder strategy output from initiative context and stakeholder details. +- If critical stakeholder context is missing, ask exactly 3 targeted questions; if still unclear, state assumptions and proceed. +- Produce: +- A Power-Interest 2x2 matrix with named stakeholders per quadrant. +- An Influence Pyramid (Top/Middle/Base) including informal power roles (gatekeepers, super-connectors, executive assistants where relevant). +- High-power stakeholder profiles covering goals/metrics, concerns/risks, preferred comms style, and political risks. +- Decision-making profile covering role identity, expected role behavior, likely information filters, in-group/out-group dynamics, and susceptibility to role pressure when relevant. +- A tailored engagement plan per high-power stakeholder (cadence/channel, format/owner, key message, quick win, fallback). +- A plan to inform/mobilize high-interest low-power stakeholders. +- Success signals/metrics and top 3 prioritized political pitfalls with mitigations. + +FORMAT +Return exactly this structure: + +Power-Interest Matrix +| Quadrant | Stakeholders | +| --- | --- | +| High Power / High Interest | [names] | +| High Power / Low Interest | [names] | +| Low Power / High Interest | [names] | +| Low Power / Low Interest | [names] | + +Influence Pyramid +- Top: [names + rationale] +- Middle: [names + rationale] +- Base: [names + rationale] + +High-Power Profiles +| Stakeholder | Goals & Success Metrics | Likely Concerns/Risks | Role Identity / Expected Behavior | Preferred Communication Style | Political Risks for Me | +| --- | --- | --- | --- | --- | --- | +| [row] | [row] | [row] | [row] | [row] | [row] | + +Decision-Making Influence Risks +- Role pressure: [who may decide from role expectation rather than evidence] +- In-group / out-group effects: [groups and likely interpretation gap] +- Authority or conformity risk: [risk and mitigation] +- Common-information risk: [shared info that may crowd out unique evidence] + +Engagement Plan +| Stakeholder | Cadence & Channel | Format | Owner | Key Message | Quick Win | Fallback | +| --- | --- | --- | --- | --- | --- | --- | +| [row] | [row] | [row] | [row] | [row] | [row] | [row] | + +Advocacy Plan (High-Interest / Low-Power) +- [how to inform] +- [how to mobilize advocacy] + +Success Signals & Metrics +- [signal/metric] + +Risks & Mitigations +1. [pitfall + mitigation] +2. [pitfall + mitigation] +3. [pitfall + mitigation] + +Assumptions +- [assumption or "None"] + +FAILURE +- Any required section/table is missing or materially incomplete. +- High-power stakeholders are not profiled and mapped to tailored engagement actions. +- Informal influence is ignored or unsupported. +- Role identity, in-group/out-group effects, or group decision influence risks are ignored when relevant. +- Top 3 political pitfalls and mitigations are missing, unprioritized, or generic. +- Claims are generic or not grounded in provided inputs. +- Assumptions are used but not explicitly stated. + +## Extended Reference + +Load `references/extended-reference.md` when the request mentions `power interest grid`, `stakeholder communication plan`, `raci`, `escalation path`. Use this reference material to sharpen this Productize skill. diff --git a/.agents/skills/productize-stakeholder-power-interest-and-influence-map/agents/openai.yaml b/skills/productize-stakeholder-power-interest-and-influence-map/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-stakeholder-power-interest-and-influence-map/agents/openai.yaml rename to skills/productize-stakeholder-power-interest-and-influence-map/agents/openai.yaml diff --git a/skills/productize-stakeholder-power-interest-and-influence-map/references/extended-reference.md b/skills/productize-stakeholder-power-interest-and-influence-map/references/extended-reference.md new file mode 100644 index 00000000..8bdc7256 --- /dev/null +++ b/skills/productize-stakeholder-power-interest-and-influence-map/references/extended-reference.md @@ -0,0 +1,58 @@ +# Extended Reference + +Use this reference to add a power-interest grid, quadrant-specific communication plan, escalation path, and optional RACI matrix. + +## Routing Signals + +- power interest grid +- stakeholder communication plan +- raci +- escalation path + + +## Stakeholder Mapping & Communication Plan + +Map stakeholders on a Power x Interest grid and create a tailored communication plan for each group. + +### Context + +You are helping build a stakeholder map for **$ARGUMENTS**. + +If the user provides files (org charts, project briefs, team rosters), read them first. If they describe the product or initiative, use that context to infer likely stakeholders. + +### Instructions + +1. **Identify stakeholders**: List all relevant individuals and groups -- executives, engineering leads, designers, marketing, sales, support, legal, finance, external partners, and end users. + +2. **Classify each stakeholder** on two dimensions: + - **Power** (High/Low): Their ability to influence decisions, resources, or outcomes + - **Interest** (High/Low): How much the project directly affects them or how engaged they are + +3. **Place stakeholders in the Power x Interest grid**: + + | | High Interest | Low Interest | + |---|---|---| + | **High Power** | **Manage Closely** -- Regular 1:1s, involve in decisions, seek their input early | **Keep Satisfied** -- Periodic updates, escalate only critical issues | + | **Low Power** | **Keep Informed** -- Regular status updates, invite to demos, gather feedback | **Monitor** -- Light-touch updates, available on request | + +4. **For each quadrant**, recommend: + - Communication frequency (daily, weekly, bi-weekly, monthly) + - Communication format (1:1, email, Slack, meeting, dashboard) + - Key messages and framing + - Potential risks if this stakeholder is neglected + +5. **Create a communication plan table**: + + | Stakeholder | Role | Power | Interest | Strategy | Frequency | Channel | Key Message | + |---|---|---|---|---|---|---|---| + +6. **Flag potential conflicts**: Identify stakeholders with competing interests and suggest alignment strategies. + +Think step by step. Save the stakeholder map as a markdown document. + +--- + +### Further Reading + +- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium) +- [Team Topologies: A Handbook to Set and Scale Product Teams](https://www.productcompass.pm/p/team-topologies-a-handbook-to-set) diff --git a/.agents/skills/productize-stakeholder-risk-review-for-a-feature-or-prd/SKILL.md b/skills/productize-stakeholder-risk-review-for-a-feature-or-prd/SKILL.md similarity index 100% rename from .agents/skills/productize-stakeholder-risk-review-for-a-feature-or-prd/SKILL.md rename to skills/productize-stakeholder-risk-review-for-a-feature-or-prd/SKILL.md diff --git a/.agents/skills/productize-stakeholder-risk-review-for-a-feature-or-prd/agents/openai.yaml b/skills/productize-stakeholder-risk-review-for-a-feature-or-prd/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-stakeholder-risk-review-for-a-feature-or-prd/agents/openai.yaml rename to skills/productize-stakeholder-risk-review-for-a-feature-or-prd/agents/openai.yaml diff --git a/.agents/skills/productize-stakeholder-update/SKILL.md b/skills/productize-stakeholder-update/SKILL.md similarity index 100% rename from .agents/skills/productize-stakeholder-update/SKILL.md rename to skills/productize-stakeholder-update/SKILL.md diff --git a/.agents/skills/productize-stakeholder-update/agents/openai.yaml b/skills/productize-stakeholder-update/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-stakeholder-update/agents/openai.yaml rename to skills/productize-stakeholder-update/agents/openai.yaml diff --git a/skills/productize-startup-canvas/SKILL.md b/skills/productize-startup-canvas/SKILL.md new file mode 100644 index 00000000..eaa5c2a7 --- /dev/null +++ b/skills/productize-startup-canvas/SKILL.md @@ -0,0 +1,219 @@ +--- +name: productize-startup-canvas +description: >- + Startup Canvas. Use when evaluating a startup concept or new product that needs product + strategy and business model logic in one founder-ready artifact. +--- + + + +# Startup Canvas + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `startup-canvas` +- **Lifecycle**: Think +- **Category**: Venture / 0-1 +- **Primary artifact**: Startup Canvas combining product strategy, business model, risks, and next validation steps + +Use when evaluating a startup concept or new product that needs product strategy and business model logic in one founder-ready artifact. + +## Productize Contract + +- **Primary lifecycle**: Think +- **Supporting lifecycle**: Strategize +- **Primary artifact**: Startup Canvas combining product strategy, business model, risks, and next validation steps +- **Source method**: pm-skills-main/pm-product-strategy/skills/startup-canvas/SKILL.md + +## Method + +## Metadata +- **Name**: startup-canvas +- **Description**: Generate a Startup Canvas for a new product. Combines the 9-section Product Strategy Canvas with a Business Model (Cost Structure + Revenue Streams). Designed specifically for startups and new products. +- **Triggers**: startup canvas, new product canvas, startup strategy, startup business model + +## Domain Context + +### Startup Canvas vs Business Model Canvas vs Lean Canvas + +Popular approaches like Business Model Canvas (Strategyzer) and Lean Canvas (Ash Maurya) mix strategy and business model into one artifact. The **Startup Canvas** (Pawe Huryn) separates them: 9 strategy sections from the Product Strategy Canvas + Cost Structure & Revenue Streams. + +**Why not Business Model Canvas?** +- No vision -- why should your team wake up every day? +- No Can't/Won't test -- what stops competitors from copying you? +- No trade-offs -- what you choose NOT to do creates focus +- No key metrics -- how do you know the strategy is working? +- Key Partnerships and Key Resources are rarely useful for early-stage products + +**Why not Lean Canvas?** +- Introduces redundancy: "Problem" overlaps with Market Segments (markets are defined by problems), "Solution" overlaps with Value Proposition (which by definition includes features) +- No vision, no trade-offs, no relative costs +- "Unfair Advantage" is too narrow -- the entire strategy should be hard to copy, not just one element +- Doesn't address the holistic fit of strategic choices reinforcing each other + +**When to use which:** +- **Business Model Canvas**: Established businesses, corporate strategy, investor materials +- **Lean Canvas**: Quick hypothesis testing when you just need speed +- **Startup Canvas**: New products where you need both strategic clarity AND a business model -- the recommended approach + +## Instructions + +You are a product strategist and startup advisor designing a Startup Canvas for $ARGUMENTS. + +Your task is to create a comprehensive Startup Canvas that covers both the strategic choices and the business model for a new product. + +## Input Requirements +- Product or startup idea +- Target market and customer insights +- Competitive landscape +- Founder/team constraints and resources + +## Startup Canvas Template + +### Part 1: Product Strategy (9 Sections) + +**1. Vision** +- How can we inspire people? What are we aspiring to achieve? What values do we uphold? +- Start simple. Your vision will evolve alongside the strategy. + +**2. Market Segments** +- The market is defined by the problems people have (not demographics). +- Jobs to Be Done (JTBD), desired outcomes, constraints. +- What will be your first customer segment? Why this one first? + +**3. Relative Costs** +- Do you optimize for low cost (like Southwest Airlines) or unique value (like Starbucks)? +- Low costs don't necessarily mean low prices. + +**4. Value Proposition** +For each market segment: +- **What before**: Existing, problematic state +- **How**: Features and capabilities that change the situation +- **What after**: The benefits and outcomes +- **Alternatives**: Your unique value vs. competitors and substitutes (consider a Value Curve) + +**5. Trade-offs** +- What will you NOT do? Trade-offs create focus and amplify value. +- Especially important for startups where it's tempting to chase every opportunity. + +**6. Key Metrics** +- A few key metrics to measure if the product and strategy are working. +- North Star Metric and One Metric That Matters (OMTM) for this quarter. + +**7. Growth** +- Product-Led Growth or Sales-Led Growth? +- Preferred channels: Social Media, SEO, Influencers, Resellers? + +**8. Capabilities** +- What competencies and resources do you need to acquire? +- What do you build vs. partner for? + +**9. Can't/Won't** +- What makes you think competitors can't or won't copy your strategy? +- The entire strategy should be difficult to copy -- not just one element. +- Do all elements fit together and reinforce each other? + +### Part 2: Business Model + +**10. Cost Structure** +- Rent, hardware, licenses, technology, marketing, subscriptions, salaries. +- Which are recurring? How will they scale? + +**11. Revenue Streams** +- How much money from each channel? +- Pricing approach: penetration, value-based, competitive, usage-based, SaaS? +- Is the revenue model scalable? What are the biggest uncertainties? + +## Output Process +1. Define the vision and aspirational impact +2. Identify 2-3 target market segments with JTBD +3. Establish cost positioning (low cost vs premium) +4. Develop value propositions for each segment +5. List explicit trade-offs +6. Set North Star and quarterly OMTM +7. Outline growth strategy and channels +8. Document required capabilities +9. Explain defensibility (Can't/Won't test) +10. Estimate cost structure and revenue streams +11. Validate strategy coherence: do all elements reinforce each other? +12. Surface hypotheses that must be true for success +13. Suggest low-effort experiments to test key assumptions + +## Notes +- The Startup Canvas separates strategy from business model -- keep them distinct but connected +- Strategy should pass the Can't/Won't test: your competitors can't or won't copy the integrated set of choices +- After drafting the first version, identify and start testing hypotheses +- Mix and adapt approaches to suit your specific needs rather than following any canvas rigidly + +--- + +### Templates + +- [Startup Canvas (PPTX)](https://docs.google.com/presentation/d/1lA0SPflj5JT6jFV_jIDsqZJAYYperTFx/edit?usp=sharing&ouid=111307342557889008106&rtpof=true&sd=true) + +--- + +### Further Reading + +- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) +- [Product Strategy Canvas](https://www.productcompass.pm/p/product-strategy-canvas) +- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) +- [Business Model Canvas Examples: Google Maps, Airbnb, Uber](https://www.productcompass.pm/p/business-model-canvas-examples) + +## Productize Output Rules + +- Produce the artifact named in the Productize contract, not a generic framework summary. +- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. +- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. +- If this reference method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-startup-canvas/agents/openai.yaml b/skills/productize-startup-canvas/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-startup-canvas/agents/openai.yaml rename to skills/productize-startup-canvas/agents/openai.yaml diff --git a/.agents/skills/productize-statistical-analysis/SKILL.md b/skills/productize-statistical-analysis/SKILL.md similarity index 100% rename from .agents/skills/productize-statistical-analysis/SKILL.md rename to skills/productize-statistical-analysis/SKILL.md diff --git a/.agents/skills/productize-statistical-analysis/agents/openai.yaml b/skills/productize-statistical-analysis/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-statistical-analysis/agents/openai.yaml rename to skills/productize-statistical-analysis/agents/openai.yaml diff --git a/.agents/skills/productize-strategic-crux-diagnosis-and-strategy-design/SKILL.md b/skills/productize-strategic-crux-diagnosis-and-strategy-design/SKILL.md similarity index 100% rename from .agents/skills/productize-strategic-crux-diagnosis-and-strategy-design/SKILL.md rename to skills/productize-strategic-crux-diagnosis-and-strategy-design/SKILL.md diff --git a/.agents/skills/productize-strategic-crux-diagnosis-and-strategy-design/agents/openai.yaml b/skills/productize-strategic-crux-diagnosis-and-strategy-design/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-strategic-crux-diagnosis-and-strategy-design/agents/openai.yaml rename to skills/productize-strategic-crux-diagnosis-and-strategy-design/agents/openai.yaml diff --git a/.agents/skills/productize-strategic-decision-making-quality-review/SKILL.md b/skills/productize-strategic-decision-making-quality-review/SKILL.md similarity index 100% rename from .agents/skills/productize-strategic-decision-making-quality-review/SKILL.md rename to skills/productize-strategic-decision-making-quality-review/SKILL.md diff --git a/.agents/skills/productize-strategic-decision-making-quality-review/agents/openai.yaml b/skills/productize-strategic-decision-making-quality-review/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-strategic-decision-making-quality-review/agents/openai.yaml rename to skills/productize-strategic-decision-making-quality-review/agents/openai.yaml diff --git a/.agents/skills/productize-strategic-moves-from-swot-pairings/SKILL.md b/skills/productize-strategic-moves-from-swot-pairings/SKILL.md similarity index 100% rename from .agents/skills/productize-strategic-moves-from-swot-pairings/SKILL.md rename to skills/productize-strategic-moves-from-swot-pairings/SKILL.md diff --git a/.agents/skills/productize-strategic-moves-from-swot-pairings/agents/openai.yaml b/skills/productize-strategic-moves-from-swot-pairings/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-strategic-moves-from-swot-pairings/agents/openai.yaml rename to skills/productize-strategic-moves-from-swot-pairings/agents/openai.yaml diff --git a/.agents/skills/productize-strategic-presentation-planning-from-topic-audience-and-time/SKILL.md b/skills/productize-strategic-presentation-planning-from-topic-audience-and-time/SKILL.md similarity index 100% rename from .agents/skills/productize-strategic-presentation-planning-from-topic-audience-and-time/SKILL.md rename to skills/productize-strategic-presentation-planning-from-topic-audience-and-time/SKILL.md diff --git a/.agents/skills/productize-strategic-presentation-planning-from-topic-audience-and-time/agents/openai.yaml b/skills/productize-strategic-presentation-planning-from-topic-audience-and-time/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-strategic-presentation-planning-from-topic-audience-and-time/agents/openai.yaml rename to skills/productize-strategic-presentation-planning-from-topic-audience-and-time/agents/openai.yaml diff --git a/.agents/skills/productize-strategy-curve-blue-ocean/SKILL.md b/skills/productize-strategy-curve-blue-ocean/SKILL.md similarity index 100% rename from .agents/skills/productize-strategy-curve-blue-ocean/SKILL.md rename to skills/productize-strategy-curve-blue-ocean/SKILL.md diff --git a/.agents/skills/productize-strategy-curve-blue-ocean/agents/openai.yaml b/skills/productize-strategy-curve-blue-ocean/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-strategy-curve-blue-ocean/agents/openai.yaml rename to skills/productize-strategy-curve-blue-ocean/agents/openai.yaml diff --git a/.agents/skills/productize-strategy-kernel-extraction-from-context/SKILL.md b/skills/productize-strategy-kernel-extraction-from-context/SKILL.md similarity index 100% rename from .agents/skills/productize-strategy-kernel-extraction-from-context/SKILL.md rename to skills/productize-strategy-kernel-extraction-from-context/SKILL.md diff --git a/.agents/skills/productize-strategy-kernel-extraction-from-context/agents/openai.yaml b/skills/productize-strategy-kernel-extraction-from-context/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-strategy-kernel-extraction-from-context/agents/openai.yaml rename to skills/productize-strategy-kernel-extraction-from-context/agents/openai.yaml diff --git a/.agents/skills/productize-strategy-to-execution-bridge-for-ux-decisions/SKILL.md b/skills/productize-strategy-to-execution-bridge-for-ux-decisions/SKILL.md similarity index 100% rename from .agents/skills/productize-strategy-to-execution-bridge-for-ux-decisions/SKILL.md rename to skills/productize-strategy-to-execution-bridge-for-ux-decisions/SKILL.md diff --git a/.agents/skills/productize-strategy-to-execution-bridge-for-ux-decisions/agents/openai.yaml b/skills/productize-strategy-to-execution-bridge-for-ux-decisions/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-strategy-to-execution-bridge-for-ux-decisions/agents/openai.yaml rename to skills/productize-strategy-to-execution-bridge-for-ux-decisions/agents/openai.yaml diff --git a/.agents/skills/productize-structured-decision-journals-from-decisions-and-context/SKILL.md b/skills/productize-structured-decision-journals-from-decisions-and-context/SKILL.md similarity index 100% rename from .agents/skills/productize-structured-decision-journals-from-decisions-and-context/SKILL.md rename to skills/productize-structured-decision-journals-from-decisions-and-context/SKILL.md diff --git a/.agents/skills/productize-structured-decision-journals-from-decisions-and-context/agents/openai.yaml b/skills/productize-structured-decision-journals-from-decisions-and-context/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-decision-journals-from-decisions-and-context/agents/openai.yaml rename to skills/productize-structured-decision-journals-from-decisions-and-context/agents/openai.yaml diff --git a/.agents/skills/productize-structured-insight-extraction-from-conversation-transcripts/SKILL.md b/skills/productize-structured-insight-extraction-from-conversation-transcripts/SKILL.md similarity index 100% rename from .agents/skills/productize-structured-insight-extraction-from-conversation-transcripts/SKILL.md rename to skills/productize-structured-insight-extraction-from-conversation-transcripts/SKILL.md diff --git a/.agents/skills/productize-structured-insight-extraction-from-conversation-transcripts/agents/openai.yaml b/skills/productize-structured-insight-extraction-from-conversation-transcripts/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-insight-extraction-from-conversation-transcripts/agents/openai.yaml rename to skills/productize-structured-insight-extraction-from-conversation-transcripts/agents/openai.yaml diff --git a/skills/productize-structured-interview-notes-from-transcript-using-flexible/SKILL.md b/skills/productize-structured-interview-notes-from-transcript-using-flexible/SKILL.md new file mode 100644 index 00000000..b51fc543 --- /dev/null +++ b/skills/productize-structured-interview-notes-from-transcript-using-flexible/SKILL.md @@ -0,0 +1,141 @@ +--- +name: productize-structured-interview-notes-from-transcript-using-flexible +description: >- + Structured interview notes from transcript using flexible frameworks. Use when the user + needs a product workflow for user research related to structured interview notes from + transcript using flexible frameworks. Trigger terms: user-research, interviews, transcripts. +--- + + + +# Structured interview notes from transcript using flexible frameworks + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `structured-interview-notes-from-transcript-using-flexible` +- **Lifecycle**: Discover +- **Category**: Discovery +- **Primary artifact**: Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps + +Use this skill to run the Productize prompt contract for **Structured interview notes from transcript using flexible frameworks**. + +## Instructions + +1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. +2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. +3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. +4. Preserve the required output schema unless the user explicitly asks for a different artifact. +5. Keep claims grounded in the provided inputs and disclose gaps. + +## Prompt Contract + +INPUTS + +- `{{INTERVIEW_TRANSCRIPT}}`: Source interview transcript. +- `{{NOTE_TAKING_MODE}}`: One of `Chronological`, `Topical`, `AEIOU Framework`, `Empathy Map`. + + +GOAL +Convert interview transcripts into concise, evidence-grounded structured notes using a selected note-taking framework. +Success metric: +- Notes are concise, atomic, and traceable to transcript content. +- Organization strictly follows the selected note-taking mode. +- Output uses the required tagged structure and one-column table format. + +CONSTRAINTS +- Use only provided inputs; if data is unclear, include explicit assumptions inside `` under an `Assumptions` subsection. +- Output only final notes wrapped in `` tags. +- Every note must: +- Capture exactly one idea. +- Be under 250 characters. +- Be grounded in transcript evidence. +- Use one-column markdown tables with clear category headers. +- Apply mode-specific organization: +- `Chronological`: single table ordered by transcript sequence. +- `Topical`: separate tables by major themes. +- `AEIOU Framework`: exactly five tables: Activities, Environments, Interactions, Objects, Users. +- `Empathy Map`: exactly eight tables: Thinks, Feels, Says, Does, Sees, Hears, Pains, Goals. +- If `{{NOTE_TAKING_MODE}}` is invalid or missing, default to `Topical` and record this in `Assumptions`. + +FORMAT +Return exactly this structure: + + +[Mode label] + +[Category Header] +| Note | +| --- | +| [One atomic note under 250 chars] | +| [One atomic note under 250 chars] | + +[Repeat tables according to selected mode] + +Assumptions (only if needed) +| Note | +| --- | +| [Explicit assumption due to missing/ambiguous data] | + + +FAILURE +- `` wrapper is missing or malformed. +- Tables are missing, not one-column, unlabeled, or not aligned with selected/default mode. +- Required mode categories are missing (AEIOU or Empathy Map). +- Notes exceed 250 characters, combine multiple ideas, or are not transcript-grounded. +- Output includes analysis/explanations outside structured notes. +- Assumptions are needed but not explicitly listed. + +## Extended Reference + +Load `references/extended-reference.md` when the request mentions `summarize interview`, `interview notes`, `satisfaction signals`, `action items`. Use this reference material to sharpen this Productize skill. diff --git a/.agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/agents/openai.yaml b/skills/productize-structured-interview-notes-from-transcript-using-flexible/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-interview-notes-from-transcript-using-flexible/agents/openai.yaml rename to skills/productize-structured-interview-notes-from-transcript-using-flexible/agents/openai.yaml diff --git a/skills/productize-structured-interview-notes-from-transcript-using-flexible/references/extended-reference.md b/skills/productize-structured-interview-notes-from-transcript-using-flexible/references/extended-reference.md new file mode 100644 index 00000000..3757cc7f --- /dev/null +++ b/skills/productize-structured-interview-notes-from-transcript-using-flexible/references/extended-reference.md @@ -0,0 +1,60 @@ +# Extended Reference + +Use this reference to make interview transcript summaries include JTBD, satisfaction signals, quotes, and action items. + +## Routing Signals + +- summarize interview +- interview notes +- satisfaction signals +- action items + + +## Summarize Customer Interview + +Transform an interview transcript into a structured summary focused on Jobs to Be Done, satisfaction, and action items. + +### Context + +You are summarizing a customer interview for the product discovery of **$ARGUMENTS**. + +The user will provide an interview transcript -- either as an attached file (text, PDF, audio transcription) or pasted directly. Read any attached files first. + +### Instructions + +1. **Read the full transcript** carefully before summarizing. + +2. **Fill in the summary template** below. Use "-" if information is unavailable. Replace numeric values with qualitative descriptions if needed (e.g., "not satisfied"). + +3. **Use clear, simple language** -- a primary school graduate should be able to understand the summary. + +### Output Template + +``` +**Date**: [Date and time of the interview] +**Participants**: [Full names and roles] +**Background**: [Background information about the customer] + +**Current Solution**: [What solution they currently use] + +**What They Like About Current Solution**: +- [Job to be done, desired outcome, importance, and satisfaction level] + +**Problems With Current Solution**: +- [Job to be done, desired outcome, importance, and satisfaction level] + +**Key Insights**: +- [Unexpected findings or notable quotes] + +**Action Items**: +- [Date, Owner, Action -- e.g., "2025-01-15, Pawe Huryn, Follow up with customer about pricing"] +``` + +Save the summary as a markdown document in the user's workspace. + +--- + +### Further Reading + +- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) +- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) diff --git a/.agents/skills/productize-structured-json-descriptions-from-ui-screenshots/SKILL.md b/skills/productize-structured-json-descriptions-from-ui-screenshots/SKILL.md similarity index 100% rename from .agents/skills/productize-structured-json-descriptions-from-ui-screenshots/SKILL.md rename to skills/productize-structured-json-descriptions-from-ui-screenshots/SKILL.md diff --git a/.agents/skills/productize-structured-json-descriptions-from-ui-screenshots/agents/openai.yaml b/skills/productize-structured-json-descriptions-from-ui-screenshots/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-json-descriptions-from-ui-screenshots/agents/openai.yaml rename to skills/productize-structured-json-descriptions-from-ui-screenshots/agents/openai.yaml diff --git a/.agents/skills/productize-structured-product-hypotheses-from-product-problems/SKILL.md b/skills/productize-structured-product-hypotheses-from-product-problems/SKILL.md similarity index 100% rename from .agents/skills/productize-structured-product-hypotheses-from-product-problems/SKILL.md rename to skills/productize-structured-product-hypotheses-from-product-problems/SKILL.md diff --git a/.agents/skills/productize-structured-product-hypotheses-from-product-problems/agents/openai.yaml b/skills/productize-structured-product-hypotheses-from-product-problems/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-product-hypotheses-from-product-problems/agents/openai.yaml rename to skills/productize-structured-product-hypotheses-from-product-problems/agents/openai.yaml diff --git a/.agents/skills/productize-structured-product-strategy-from-product-context/SKILL.md b/skills/productize-structured-product-strategy-from-product-context/SKILL.md similarity index 100% rename from .agents/skills/productize-structured-product-strategy-from-product-context/SKILL.md rename to skills/productize-structured-product-strategy-from-product-context/SKILL.md diff --git a/.agents/skills/productize-structured-product-strategy-from-product-context/agents/openai.yaml b/skills/productize-structured-product-strategy-from-product-context/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-product-strategy-from-product-context/agents/openai.yaml rename to skills/productize-structured-product-strategy-from-product-context/agents/openai.yaml diff --git a/.agents/skills/productize-structured-requirements-from-conversation-transcripts/SKILL.md b/skills/productize-structured-requirements-from-conversation-transcripts/SKILL.md similarity index 100% rename from .agents/skills/productize-structured-requirements-from-conversation-transcripts/SKILL.md rename to skills/productize-structured-requirements-from-conversation-transcripts/SKILL.md diff --git a/.agents/skills/productize-structured-requirements-from-conversation-transcripts/agents/openai.yaml b/skills/productize-structured-requirements-from-conversation-transcripts/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-requirements-from-conversation-transcripts/agents/openai.yaml rename to skills/productize-structured-requirements-from-conversation-transcripts/agents/openai.yaml diff --git a/.agents/skills/productize-structured-requirements-from-design-assets/SKILL.md b/skills/productize-structured-requirements-from-design-assets/SKILL.md similarity index 100% rename from .agents/skills/productize-structured-requirements-from-design-assets/SKILL.md rename to skills/productize-structured-requirements-from-design-assets/SKILL.md diff --git a/.agents/skills/productize-structured-requirements-from-design-assets/agents/openai.yaml b/skills/productize-structured-requirements-from-design-assets/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-structured-requirements-from-design-assets/agents/openai.yaml rename to skills/productize-structured-requirements-from-design-assets/agents/openai.yaml diff --git a/.agents/skills/productize-success-metrics-for-design-decisions/SKILL.md b/skills/productize-success-metrics-for-design-decisions/SKILL.md similarity index 100% rename from .agents/skills/productize-success-metrics-for-design-decisions/SKILL.md rename to skills/productize-success-metrics-for-design-decisions/SKILL.md diff --git a/.agents/skills/productize-success-metrics-for-design-decisions/agents/openai.yaml b/skills/productize-success-metrics-for-design-decisions/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-success-metrics-for-design-decisions/agents/openai.yaml rename to skills/productize-success-metrics-for-design-decisions/agents/openai.yaml diff --git a/.agents/skills/productize-support-tickets-as-actionable-product-improvements/SKILL.md b/skills/productize-support-tickets-as-actionable-product-improvements/SKILL.md similarity index 100% rename from .agents/skills/productize-support-tickets-as-actionable-product-improvements/SKILL.md rename to skills/productize-support-tickets-as-actionable-product-improvements/SKILL.md diff --git a/.agents/skills/productize-support-tickets-as-actionable-product-improvements/agents/openai.yaml b/skills/productize-support-tickets-as-actionable-product-improvements/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-support-tickets-as-actionable-product-improvements/agents/openai.yaml rename to skills/productize-support-tickets-as-actionable-product-improvements/agents/openai.yaml diff --git a/.agents/skills/productize-sustainable-business-model/SKILL.md b/skills/productize-sustainable-business-model/SKILL.md similarity index 100% rename from .agents/skills/productize-sustainable-business-model/SKILL.md rename to skills/productize-sustainable-business-model/SKILL.md diff --git a/.agents/skills/productize-sustainable-business-model/agents/openai.yaml b/skills/productize-sustainable-business-model/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-sustainable-business-model/agents/openai.yaml rename to skills/productize-sustainable-business-model/agents/openai.yaml diff --git a/.agents/skills/productize-sustainable-business-model/references/output-format.md b/skills/productize-sustainable-business-model/references/output-format.md similarity index 100% rename from .agents/skills/productize-sustainable-business-model/references/output-format.md rename to skills/productize-sustainable-business-model/references/output-format.md diff --git a/.agents/skills/productize-sustainable-business-model/references/pattern-groups.md b/skills/productize-sustainable-business-model/references/pattern-groups.md similarity index 100% rename from .agents/skills/productize-sustainable-business-model/references/pattern-groups.md rename to skills/productize-sustainable-business-model/references/pattern-groups.md diff --git a/.agents/skills/productize-synthesize-research/SKILL.md b/skills/productize-synthesize-research/SKILL.md similarity index 100% rename from .agents/skills/productize-synthesize-research/SKILL.md rename to skills/productize-synthesize-research/SKILL.md diff --git a/.agents/skills/productize-synthesize-research/agents/openai.yaml b/skills/productize-synthesize-research/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-synthesize-research/agents/openai.yaml rename to skills/productize-synthesize-research/agents/openai.yaml diff --git a/.agents/skills/productize-systematic-debugging/SKILL.md b/skills/productize-systematic-debugging/SKILL.md similarity index 100% rename from .agents/skills/productize-systematic-debugging/SKILL.md rename to skills/productize-systematic-debugging/SKILL.md diff --git a/.agents/skills/productize-systematic-debugging/agents/openai.yaml b/skills/productize-systematic-debugging/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-systematic-debugging/agents/openai.yaml rename to skills/productize-systematic-debugging/agents/openai.yaml diff --git a/.agents/skills/productize-target-opportunity-selection-from-ost/SKILL.md b/skills/productize-target-opportunity-selection-from-ost/SKILL.md similarity index 100% rename from .agents/skills/productize-target-opportunity-selection-from-ost/SKILL.md rename to skills/productize-target-opportunity-selection-from-ost/SKILL.md diff --git a/.agents/skills/productize-target-opportunity-selection-from-ost/agents/openai.yaml b/skills/productize-target-opportunity-selection-from-ost/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-target-opportunity-selection-from-ost/agents/openai.yaml rename to skills/productize-target-opportunity-selection-from-ost/agents/openai.yaml diff --git a/.agents/skills/productize-task-list-optimization-and-contingency-based-project-planning/SKILL.md b/skills/productize-task-list-optimization-and-contingency-based-project-planning/SKILL.md similarity index 100% rename from .agents/skills/productize-task-list-optimization-and-contingency-based-project-planning/SKILL.md rename to skills/productize-task-list-optimization-and-contingency-based-project-planning/SKILL.md diff --git a/.agents/skills/productize-task-list-optimization-and-contingency-based-project-planning/agents/openai.yaml b/skills/productize-task-list-optimization-and-contingency-based-project-planning/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-task-list-optimization-and-contingency-based-project-planning/agents/openai.yaml rename to skills/productize-task-list-optimization-and-contingency-based-project-planning/agents/openai.yaml diff --git a/.agents/skills/productize-task-specific-product-strategy-design/SKILL.md b/skills/productize-task-specific-product-strategy-design/SKILL.md similarity index 100% rename from .agents/skills/productize-task-specific-product-strategy-design/SKILL.md rename to skills/productize-task-specific-product-strategy-design/SKILL.md diff --git a/.agents/skills/productize-task-specific-product-strategy-design/agents/openai.yaml b/skills/productize-task-specific-product-strategy-design/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-task-specific-product-strategy-design/agents/openai.yaml rename to skills/productize-task-specific-product-strategy-design/agents/openai.yaml diff --git a/.agents/skills/productize-tdd/SKILL.md b/skills/productize-tdd/SKILL.md similarity index 100% rename from .agents/skills/productize-tdd/SKILL.md rename to skills/productize-tdd/SKILL.md diff --git a/.agents/skills/productize-tdd/agents/openai.yaml b/skills/productize-tdd/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-tdd/agents/openai.yaml rename to skills/productize-tdd/agents/openai.yaml diff --git a/.agents/skills/productize-technical-architecture-brief-from-product-requirements-doc/SKILL.md b/skills/productize-technical-architecture-brief-from-product-requirements-doc/SKILL.md similarity index 100% rename from .agents/skills/productize-technical-architecture-brief-from-product-requirements-doc/SKILL.md rename to skills/productize-technical-architecture-brief-from-product-requirements-doc/SKILL.md diff --git a/.agents/skills/productize-technical-architecture-brief-from-product-requirements-doc/agents/openai.yaml b/skills/productize-technical-architecture-brief-from-product-requirements-doc/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-technical-architecture-brief-from-product-requirements-doc/agents/openai.yaml rename to skills/productize-technical-architecture-brief-from-product-requirements-doc/agents/openai.yaml diff --git a/.agents/skills/productize-technical-translation-and-stakeholder-communication/SKILL.md b/skills/productize-technical-translation-and-stakeholder-communication/SKILL.md similarity index 100% rename from .agents/skills/productize-technical-translation-and-stakeholder-communication/SKILL.md rename to skills/productize-technical-translation-and-stakeholder-communication/SKILL.md diff --git a/.agents/skills/productize-technical-translation-and-stakeholder-communication/agents/openai.yaml b/skills/productize-technical-translation-and-stakeholder-communication/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-technical-translation-and-stakeholder-communication/agents/openai.yaml rename to skills/productize-technical-translation-and-stakeholder-communication/agents/openai.yaml diff --git a/skills/productize-test-scenarios/SKILL.md b/skills/productize-test-scenarios/SKILL.md new file mode 100644 index 00000000..fe4e4891 --- /dev/null +++ b/skills/productize-test-scenarios/SKILL.md @@ -0,0 +1,167 @@ +--- +name: productize-test-scenarios +description: >- + Test Scenarios. Use when creating test scenarios from user stories, feature specs, PRDs, + acceptance criteria, or agent-ready implementation plans. +--- + + + +# Test Scenarios + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `test-scenarios` +- **Lifecycle**: Build With AI +- **Category**: Delivery +- **Primary artifact**: QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix + +Use when creating test scenarios from user stories, feature specs, PRDs, acceptance criteria, or agent-ready implementation plans. + +## Productize Contract + +- **Primary lifecycle**: Build With AI +- **Supporting lifecycle**: Launch & Learn +- **Primary artifact**: QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix +- **Source method**: pm-skills-main/pm-execution/skills/test-scenarios/SKILL.md + +## Method + +Create comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step test actions, and expected outcomes. + +**Use when:** Writing QA test cases, creating test plans, defining acceptance test scenarios, or validating user story implementations. + +**Arguments:** +- `$PRODUCT`: The product or system name +- `$USER_STORY`: The user story to test (title and acceptance criteria) +- `$CONTEXT`: Additional testing context or constraints + +## Step-by-Step Process + +1. **Review the user story** and acceptance criteria +2. **Define test objectives** - What specific behavior to validate +3. **Establish starting conditions** - System state, data setup, configurations +4. **Identify user roles** - Who performs the test actions +5. **Create test steps** - Break down interactions step-by-step +6. **Define expected outcomes** - Observable results after each step +7. **Consider edge cases** - Invalid inputs, boundary conditions +8. **Output detailed test scenarios** - Ready for QA execution + +## Scenario Template + +**Test Scenario:** [Clear scenario name] + +**Test Objective:** [What this test validates] + +**Starting Conditions:** +- [System state required] +- [Data or configuration needed] +- [User setup or permissions] + +**User Role:** [Who performs the test] + +**Test Steps:** +1. [First action and its expected result] +2. [Second action and observable outcome] +3. [Third action and system behavior] +4. [Completion action and final state] + +**Expected Outcomes:** +- [Observable result 1] +- [Observable result 2] +- [Observable result 3] + +## Example Test Scenario + +**Test Scenario:** View Recently Viewed Products on Product Page + +**Test Objective:** Verify that the 'Recently viewed' section displays correctly and excludes the current product. + +**Starting Conditions:** +- User is logged in or has browser history enabled +- User has viewed at least 2 products in the current session +- User is now on a product page different from previously viewed items + +**User Role:** Online Shopper + +**Test Steps:** +1. Navigate to any product page -> Section should appear at bottom with previously viewed items +2. Scroll to bottom of page -> "Recently viewed" section is visible with product cards +3. Verify product thumbnails -> Images, titles, and prices are displayed correctly +4. Check current product -> Current product is NOT in the recently viewed list +5. Click on a product card -> User navigates to the corresponding product page + +**Expected Outcomes:** +- Recently viewed section appears only after viewing at least 1 prior product +- Section displays 4-8 product cards with complete information +- Current product is excluded from the list +- Each card shows "Viewed X minutes/hours ago" timestamp +- Clicking cards navigates to correct product pages +- Performance: Section loads within 2 seconds + +## Output Deliverables + +- Comprehensive test scenarios for each acceptance criterion +- Clear test objectives aligned with user story intent +- Detailed step-by-step test actions +- Observable expected outcomes after each step +- Edge case and error scenario coverage +- Ready for QA team execution and documentation + +## Productize Output Rules + +- Produce the artifact named in the Productize contract, not a generic framework summary. +- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. +- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. +- If this reference method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-test-scenarios/agents/openai.yaml b/skills/productize-test-scenarios/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-test-scenarios/agents/openai.yaml rename to skills/productize-test-scenarios/agents/openai.yaml diff --git a/.agents/skills/productize-thesis-review/SKILL.md b/skills/productize-thesis-review/SKILL.md similarity index 100% rename from .agents/skills/productize-thesis-review/SKILL.md rename to skills/productize-thesis-review/SKILL.md diff --git a/.agents/skills/productize-thesis-review/agents/openai.yaml b/skills/productize-thesis-review/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-thesis-review/agents/openai.yaml rename to skills/productize-thesis-review/agents/openai.yaml diff --git a/.agents/skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md b/skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md similarity index 100% rename from .agents/skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md rename to skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md diff --git a/.agents/skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/agents/openai.yaml b/skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/agents/openai.yaml rename to skills/productize-trade-off-analysis-from-feature-priority-and-effort-data/agents/openai.yaml diff --git a/.agents/skills/productize-user-stories-from-initiative-requirements/SKILL.md b/skills/productize-user-stories-from-initiative-requirements/SKILL.md similarity index 100% rename from .agents/skills/productize-user-stories-from-initiative-requirements/SKILL.md rename to skills/productize-user-stories-from-initiative-requirements/SKILL.md diff --git a/.agents/skills/productize-user-stories-from-initiative-requirements/agents/openai.yaml b/skills/productize-user-stories-from-initiative-requirements/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-user-stories-from-initiative-requirements/agents/openai.yaml rename to skills/productize-user-stories-from-initiative-requirements/agents/openai.yaml diff --git a/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md b/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md new file mode 100644 index 00000000..ac6ab5e5 --- /dev/null +++ b/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md @@ -0,0 +1,142 @@ +--- +name: productize-user-stories-with-gherkin-acceptance-criteria-from-requirements +description: >- + User stories with Gherkin acceptance criteria from requirements. Use when the user needs a + product workflow for business analysis related to user stories with gherkin acceptance + criteria from requirements. Trigger terms: pm, user-stories, gherkin, requirements, + business-analysis. +--- + + + +# User stories with Gherkin acceptance criteria from requirements + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `user-stories-with-gherkin-acceptance-criteria-from-requirements` +- **Lifecycle**: Design +- **Category**: Delivery +- **Primary artifact**: User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks + +Use this skill to run the Productize prompt contract for **User stories with Gherkin acceptance criteria from requirements**. + +## Instructions + +1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. +2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. +3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. +4. Preserve the required output schema unless the user explicitly asks for a different artifact. +5. Keep claims grounded in the provided inputs and disclose gaps. + +## Prompt Contract + +INPUTS + +- [No explicit variables declared; use provided context.] + + +GOAL +Generate INVEST-compliant, atomic user stories with Gherkin acceptance criteria from provided requirements context. +Success metric: +- Produces one or more atomic user stories aligned to persona goals and constraints. +- Each story includes deterministic happy-path and edge/negative Gherkin scenarios. +- Includes traceability from requirements to stories and acceptance criteria. +- Follows the required markdown output structure exactly. + +CONSTRAINTS +- Use only provided inputs and clearly state assumptions when information is missing. +- Do not skip required steps: + 1. Decompose requirements into distinct atomic outcomes. + 2. Draft one story per outcome. + 3. Add Gherkin acceptance criteria with one `When` and one `Then` in happy path. + 4. Add at least one edge/negative scenario per story. + 5. Complete notes and traceability mapping. +- Stories must be INVEST-compliant and persona-aligned. +- If a story would require multiple primary outcomes, split it or mark `SPLIT SUGGESTED`. +- Keep language testable and implementation-neutral (unless a technical constraint is explicitly required). +- Use `[TBD]` for critical missing info and surface it under Open Questions. + +FORMAT +Return exactly this structure: + +```md +Backlog Context +[Backlog Header Template fields filled] + +User Story [ID-###]: +[Use Case + Gherkin happy-path scenario + Gherkin edge/negative scenario] +Notes +[Non-Functional, Instrumentation, Dependencies, Out of Scope, Open Questions] + +[Repeat story blocks for each atomic outcome] + +Traceability Table +[Requirement ID | Requirement Summary | Story ID(s) | AC Coverage Notes] + +Validation Checklist +[All required checklist items] +``` + +FAILURE +- Required markdown structure is missing or malformed. +- Stories are non-atomic, non-INVEST, or not mapped to clear outcomes. +- Happy-path scenario contains more than one `When` or more than one `Then` without `SPLIT SUGGESTED`. +- Edge/negative scenario is missing for any story. +- Traceability table or validation checklist is missing. +- Claims are generic or not grounded in provided inputs. +- Assumptions are used but not explicitly stated. + +## Extended Reference + +Load `references/extended-reference.md` when the request mentions `3 cs`, `invest`, `user stories`, `conversation confirmation`. Use this reference material to sharpen this Productize skill. diff --git a/.agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/agents/openai.yaml b/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/agents/openai.yaml rename to skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/agents/openai.yaml diff --git a/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/references/extended-reference.md b/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/references/extended-reference.md new file mode 100644 index 00000000..dba7ddb4 --- /dev/null +++ b/skills/productize-user-stories-with-gherkin-acceptance-criteria-from-requirements/references/extended-reference.md @@ -0,0 +1,80 @@ +# Extended Reference + +Use this reference to improve story quality with 3 Cs, INVEST checks, conversation notes, design links, and acceptance criteria. + +## Routing Signals + +- 3 cs +- invest +- user stories +- conversation confirmation + + +Create user stories following the 3 C's (Card, Conversation, Confirmation) and INVEST criteria. Generates stories with descriptions, design links, and acceptance criteria. + +**Use when:** Writing user stories, breaking down features into stories, creating backlog items, or defining acceptance criteria. + +**Arguments:** +- `$PRODUCT`: The product or system name +- `$FEATURE`: The new feature to break into stories +- `$DESIGN`: Link to design files (Figma, Miro, etc.) +- `$ASSUMPTIONS`: Key assumptions or context + +## Step-by-Step Process + +1. **Analyze the feature** based on provided design and context +2. **Identify user roles** and distinct user journeys +3. **Apply 3 C's framework:** + - Card: Simple title and one-liner + - Conversation: Detailed discussion of intent + - Confirmation: Clear acceptance criteria +4. **Respect INVEST criteria:** Independent, Negotiable, Valuable, Estimable, Small, Testable +5. **Use plain language** a primary school graduate can understand +6. **Link to design files** for visual reference +7. **Output user stories** in structured format + +## Story Template + +**Title:** [Feature name] + +**Description:** As a [user role], I want to [action], so that [benefit]. + +**Design:** [Link to design files] + +**Acceptance Criteria:** +1. [Clear, testable criterion] +2. [Observable behavior] +3. [System validates correctly] +4. [Edge case handling] +5. [Performance or accessibility consideration] +6. [Integration point] + +## Example User Story + +**Title:** Recently Viewed Section + +**Description:** As an Online Shopper, I want to see a 'Recently viewed' section on the product page to easily revisit items I considered. + +**Design:** [Figma link] + +**Acceptance Criteria:** +1. The 'Recently viewed' section is displayed at the bottom of the product page for every user who has previously viewed at least 1 product. +2. It is not displayed for users visiting the first product page of their session. +3. The current product itself is excluded from the displayed items. +4. The section showcases product cards or thumbnails with images, titles, and prices. +5. Each product card indicates when it was viewed (e.g., 'Viewed 5 minutes ago'). +6. Clicking on a product card leads the user to the corresponding product page. + +## Output Deliverables + +- Complete set of user stories for the feature +- Each story includes title, description, design link, and 4-6 acceptance criteria +- Stories are independent and can be developed in any order +- Stories are sized for one sprint cycle +- Stories reference related design documentation + +--- + +### Further Reading + +- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories) diff --git a/.agents/skills/productize-ux-edge-cases-from-product-briefs/SKILL.md b/skills/productize-ux-edge-cases-from-product-briefs/SKILL.md similarity index 100% rename from .agents/skills/productize-ux-edge-cases-from-product-briefs/SKILL.md rename to skills/productize-ux-edge-cases-from-product-briefs/SKILL.md diff --git a/.agents/skills/productize-ux-edge-cases-from-product-briefs/agents/openai.yaml b/skills/productize-ux-edge-cases-from-product-briefs/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-ux-edge-cases-from-product-briefs/agents/openai.yaml rename to skills/productize-ux-edge-cases-from-product-briefs/agents/openai.yaml diff --git a/.agents/skills/productize-ux-terminology-improvements-in-product-requirements/SKILL.md b/skills/productize-ux-terminology-improvements-in-product-requirements/SKILL.md similarity index 100% rename from .agents/skills/productize-ux-terminology-improvements-in-product-requirements/SKILL.md rename to skills/productize-ux-terminology-improvements-in-product-requirements/SKILL.md diff --git a/.agents/skills/productize-ux-terminology-improvements-in-product-requirements/agents/openai.yaml b/skills/productize-ux-terminology-improvements-in-product-requirements/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-ux-terminology-improvements-in-product-requirements/agents/openai.yaml rename to skills/productize-ux-terminology-improvements-in-product-requirements/agents/openai.yaml diff --git a/.agents/skills/productize-validate-data/SKILL.md b/skills/productize-validate-data/SKILL.md similarity index 100% rename from .agents/skills/productize-validate-data/SKILL.md rename to skills/productize-validate-data/SKILL.md diff --git a/.agents/skills/productize-validate-data/agents/openai.yaml b/skills/productize-validate-data/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-validate-data/agents/openai.yaml rename to skills/productize-validate-data/agents/openai.yaml diff --git a/.agents/skills/productize-valuation-and-deal-pricing/SKILL.md b/skills/productize-valuation-and-deal-pricing/SKILL.md similarity index 100% rename from .agents/skills/productize-valuation-and-deal-pricing/SKILL.md rename to skills/productize-valuation-and-deal-pricing/SKILL.md diff --git a/.agents/skills/productize-valuation-and-deal-pricing/agents/openai.yaml b/skills/productize-valuation-and-deal-pricing/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-valuation-and-deal-pricing/agents/openai.yaml rename to skills/productize-valuation-and-deal-pricing/agents/openai.yaml diff --git a/.agents/skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md b/skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md similarity index 100% rename from .agents/skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md rename to skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md diff --git a/.agents/skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/agents/openai.yaml b/skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/agents/openai.yaml rename to skills/productize-value-chain-mapping-from-end-user-needs-to-core-value/agents/openai.yaml diff --git a/.agents/skills/productize-venture-capital-deal-modeling/SKILL.md b/skills/productize-venture-capital-deal-modeling/SKILL.md similarity index 100% rename from .agents/skills/productize-venture-capital-deal-modeling/SKILL.md rename to skills/productize-venture-capital-deal-modeling/SKILL.md diff --git a/.agents/skills/productize-venture-capital-deal-modeling/agents/openai.yaml b/skills/productize-venture-capital-deal-modeling/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-venture-capital-deal-modeling/agents/openai.yaml rename to skills/productize-venture-capital-deal-modeling/agents/openai.yaml diff --git a/.agents/skills/productize-verification/SKILL.md b/skills/productize-verification/SKILL.md similarity index 100% rename from .agents/skills/productize-verification/SKILL.md rename to skills/productize-verification/SKILL.md diff --git a/.agents/skills/productize-verification/agents/openai.yaml b/skills/productize-verification/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-verification/agents/openai.yaml rename to skills/productize-verification/agents/openai.yaml diff --git a/.agents/skills/productize-visual-decision-making-review/SKILL.md b/skills/productize-visual-decision-making-review/SKILL.md similarity index 100% rename from .agents/skills/productize-visual-decision-making-review/SKILL.md rename to skills/productize-visual-decision-making-review/SKILL.md diff --git a/.agents/skills/productize-visual-decision-making-review/agents/openai.yaml b/skills/productize-visual-decision-making-review/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-visual-decision-making-review/agents/openai.yaml rename to skills/productize-visual-decision-making-review/agents/openai.yaml diff --git a/.agents/skills/productize-workshop-activity-design-from-problem-and-participant/SKILL.md b/skills/productize-workshop-activity-design-from-problem-and-participant/SKILL.md similarity index 100% rename from .agents/skills/productize-workshop-activity-design-from-problem-and-participant/SKILL.md rename to skills/productize-workshop-activity-design-from-problem-and-participant/SKILL.md diff --git a/.agents/skills/productize-workshop-activity-design-from-problem-and-participant/agents/openai.yaml b/skills/productize-workshop-activity-design-from-problem-and-participant/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-workshop-activity-design-from-problem-and-participant/agents/openai.yaml rename to skills/productize-workshop-activity-design-from-problem-and-participant/agents/openai.yaml diff --git a/skills/productize-write-query/SKILL.md b/skills/productize-write-query/SKILL.md new file mode 100644 index 00000000..ddaf1614 --- /dev/null +++ b/skills/productize-write-query/SKILL.md @@ -0,0 +1,210 @@ +--- +name: productize-write-query +description: >- + Write optimized SQL for a specific dialect with best practices. Use when translating a + natural language data need into SQL, building a multi-CTE query with joins and aggregations, + optimizing a large partitioned-table query, or getting Snowflake, BigQuery, Postgres, or + other dialect syntax. +--- + + + +# Write Query + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `write-query` +- **Lifecycle**: Plan +- **Category**: Analytics +- **Primary artifact**: Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria + +Write a SQL query from a natural-language description, optimized for the user's SQL dialect and use case. + +## Argument Hint + +`` + +## Usage + +```text +/write-query +``` + +## Extended Reference + +Load `references/extended-reference.md` when the request mentions `sql generator`, `bigquery`, `postgres`, `mysql`, `schema diagram`. Use this reference material to sharpen this Productize skill. + +## Workflow + +### 1. Understand the Request + +Parse the user's description to identify: +- Output columns. +- Filters: time ranges, segments, statuses, exclusions. +- Aggregations: counts, sums, averages, rates, distincts. +- Joins and required entities. +- Ordering. +- Limits, top-N, or sample requirements. +- Expected grain: one row per what. + +If the request is ambiguous, ask only for the missing detail that changes query correctness. + +### 2. Determine SQL Dialect + +If not known, ask which dialect they use: +- PostgreSQL, including Aurora, RDS, Supabase, Neon. +- Snowflake. +- BigQuery. +- Redshift. +- Databricks SQL. +- MySQL. +- SQL Server. +- DuckDB. +- SQLite. +- Other. + +Use `sql-queries` for dialect-specific syntax, date functions, semi-structured data, performance notes, and debugging. + +### 3. Discover Schema + +If a warehouse or schema tool is connected: +1. Search for relevant tables. +2. Inspect column names, types, and relationships. +3. Check partition, clustering, sort, or distribution keys. +4. Look for existing views or materialized views. + +If no warehouse is connected: +- Ask for table names, schema, or sample rows. +- If the schema is unknown, provide a query template with clearly marked placeholders. + +### 4. Write the Query + +Structure: +- Use CTEs for multi-step logic. +- Use one CTE per logical transformation or source. +- Name CTEs descriptively. +- Keep the final SELECT easy to scan. + +Performance: +- Avoid `SELECT *` in production queries. +- Filter early, especially on dates and partitions. +- Use partition filters for BigQuery/Databricks and clustering/sort-aware filters for Snowflake/Redshift. +- Use appropriate join types. +- Avoid correlated subqueries when joins or windows are clearer. +- Watch for many-to-many joins and potential row multiplication. +- Prefer approximate distinct functions only when accuracy tradeoffs are acceptable and stated. + +Readability: +- Add comments for non-obvious business logic. +- Use consistent formatting and indentation. +- Use meaningful table aliases. +- Put major clauses on their own lines. + +Correctness: +- Protect rate denominators with `NULLIF` or dialect-safe division. +- Define timezones and date boundaries. +- Deduplicate before aggregation when needed. +- Keep metric definitions explicit. + +### 5. Present the Query + +Provide: +1. Complete SQL code block. +2. Short explanation of each CTE or major section. +3. Performance notes and likely bottlenecks. +4. Modification suggestions for date range, granularity, dimensions, or filters. +5. Validation checks the user can run. + +### 6. Offer Execution or Review + +If a warehouse is connected, offer to run the query and inspect results. If the user will run it themselves, make the query copy-paste ready. + +## Output Template + +````markdown +## Query + +```sql +-- SQL here +``` + +## How It Works +- `[cte_name]`: ... + +## Performance Notes +- ... + +## Validation Checks +- Row count before and after joins. +- Date range coverage. +- Duplicate key checks. +- Aggregate reconciliation. + +## Common Modifications +- To change time range: ... +- To group by another dimension: ... +```` + +## Examples + +- Count orders by status for the last 30 days. +- Cohort retention by signup month with activity at 1, 3, 6, and 12 months. +- Top 100 users by event count in the last 7 days from a large partitioned events table. + +## Rules + +- Do not invent exact table or column names when schema is unknown; use placeholders or ask for schema. +- If using assumptions, state them next to the query. +- For recurring queries, parameterize date ranges when the dialect supports it. +- For high-stakes analysis, recommend `validate-data` after results are produced. diff --git a/.agents/skills/productize-write-query/agents/openai.yaml b/skills/productize-write-query/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-write-query/agents/openai.yaml rename to skills/productize-write-query/agents/openai.yaml diff --git a/skills/productize-write-query/references/extended-reference.md b/skills/productize-write-query/references/extended-reference.md new file mode 100644 index 00000000..1623ce67 --- /dev/null +++ b/skills/productize-write-query/references/extended-reference.md @@ -0,0 +1,93 @@ +# Extended Reference + +Use this reference to strengthen SQL generation across dialects and schema interpretation from product analytics questions. + +## Routing Signals + +- sql generator +- bigquery +- postgres +- mysql +- schema diagram + + +## Purpose +Transform natural language requirements into optimized SQL queries across multiple database platforms. This skill helps product managers, analysts, and engineers generate accurate queries without manual syntax work. + +## How It Works + +### Step 1: Understand Your Database Schema +- If you provide a schema file (SQL, documentation, or diagram description), I will read and analyze it +- Extract table names, column definitions, data types, and relationships +- Identify primary keys, foreign keys, and indexing strategies + +### Step 2: Process Your Request +- Clarify the exact data you need to retrieve or analyze +- Confirm the SQL dialect (BigQuery, PostgreSQL, MySQL, Snowflake, etc.) +- Ask for any additional requirements (filters, aggregations, sorting) + +### Step 3: Generate Optimized Query +- Write efficient SQL that leverages your database structure +- Include comments explaining complex logic +- Add performance considerations for large datasets +- Provide alternative approaches if applicable + +### Step 4: Explain and Test +- Explain the query logic in plain English +- Suggest how to test or validate results +- Offer tips for performance optimization +- If you want, generate a test script or sample data + +## Usage Examples + +**Example 1: Query from Schema File** +``` +Upload your database_schema.sql file and say: +"Generate a query to find users who signed up in the last 30 days +and had at least 5 active sessions" +``` + +**Example 2: Query from Diagram Description** +``` +"Here's my database: Users table (id, email, created_at), Sessions table +(id, user_id, timestamp, duration). Generate a query for average session +duration per user in January 2026." +``` + +**Example 3: Complex Analysis Query** +``` +"Create a BigQuery query to analyze our revenue by region and customer tier, +including year-over-year growth rates." +``` + +## Key Capabilities + +- **Multi-Dialect Support**: Works with BigQuery, PostgreSQL, MySQL, Snowflake, SQL Server +- **File Reading**: Reads schema files, SQL dumps, and data documentation +- **Query Optimization**: Suggests indexes, partitioning, and performance improvements +- **Explanation**: Breaks down queries for learning and documentation +- **Testing**: Can generate test queries and sample data scripts +- **Script Execution**: Create executable SQL scripts for your database + +## Tips for Best Results + +1. **Provide context**: Share your database schema or structure +2. **Be specific**: Clearly describe what data you need and any filters +3. **Mention database**: Specify which SQL dialect you're using +4. **Include constraints**: Mention data volume, time ranges, and performance needs +5. **Request format**: Ask for the query result format if you need specific output + +## Output Format + +You'll receive: +- **SQL Query**: Production-ready SQL code with comments +- **Explanation**: What the query does and how it works +- **Performance Notes**: Optimization tips and considerations +- **Test Script** (if requested): Sample data and validation queries + +--- + +### Further Reading + +- [The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs](https://www.productcompass.pm/p/the-product-analytics-playbook-aarrr) +- [How to Become a Technology-Literate PM](https://www.productcompass.pm/p/how-to-become-a-technology-literate) diff --git a/skills/productize-write-spec/SKILL.md b/skills/productize-write-spec/SKILL.md new file mode 100644 index 00000000..18fc549c --- /dev/null +++ b/skills/productize-write-spec/SKILL.md @@ -0,0 +1,136 @@ +--- +name: productize-write-spec +description: >- + Write a feature spec or PRD from a problem statement or feature idea. Use when turning a + vague idea into a structured document, scoping goals and non-goals, defining success metrics + and acceptance criteria, or breaking a big ask into phases. +--- + + + +# Write Spec + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `write-spec` +- **Lifecycle**: Plan +- **Category**: Delivery +- **Primary artifact**: Feature spec or PRD with scope, success metrics, and acceptance criteria + +Write a feature specification or product requirements document. + +## Argument Hint + +`` + +## Usage + +```text +/write-spec $ARGUMENTS +``` + +## Extended Reference + +Load `references/extended-reference.md` when the request mentions `create prd`, `8-section prd`, `feature spec`, `release planning`. Use this reference material to sharpen this Productize skill. + +## Workflow + +### 1. Understand the Feature + +Accept a feature name, problem statement, user request, or vague idea. + +Ask conversationally for the most important missing context: +- User problem and affected segment. +- Success metrics. +- Constraints, dependencies, deadlines. +- Prior attempts or related solutions. + +### 2. Pull Context + +If connected, search project tracker, docs, research, design files, and meeting notes for related work, requirements, mockups, decisions, and dependencies. + +If tools are not connected, proceed from user-provided context and state assumptions. + +### 3. Generate PRD + +Include: +- **Problem Statement**: 2-3 sentences with user, pain, frequency, and impact. +- **Goals**: 3-5 measurable outcomes. +- **Non-Goals**: 3-5 out-of-scope items with rationale. +- **User Stories**: "As a [user], I want [capability], so that [benefit]." +- **Requirements**: P0, P1, P2 with acceptance criteria. +- **Success Metrics**: leading and lagging indicators with targets and measurement method. +- **Open Questions**: tagged by owner and blocking status. +- **Timeline Considerations**: hard deadlines, dependencies, phasing. + +### 4. Acceptance Criteria + +Use Given/When/Then or checklist format. Cover: +- Happy path. +- Error states. +- Empty states. +- Boundary conditions. +- Negative cases. + +### 5. Scope Rules + +- Be opinionated about v1 scope. +- If everything is P0, challenge it. +- Require scope addition to come with scope removal or timeline extension. +- Separate v1 from future considerations. +- Keep requirements behavior-focused, not implementation-prescriptive unless necessary. + +## Output Rules + +Use clear markdown headers and tables where helpful. Keep the spec skimmable. Open questions must be genuinely unresolved. diff --git a/.agents/skills/productize-write-spec/agents/openai.yaml b/skills/productize-write-spec/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-write-spec/agents/openai.yaml rename to skills/productize-write-spec/agents/openai.yaml diff --git a/skills/productize-write-spec/references/extended-reference.md b/skills/productize-write-spec/references/extended-reference.md new file mode 100644 index 00000000..d97bf900 --- /dev/null +++ b/skills/productize-write-spec/references/extended-reference.md @@ -0,0 +1,91 @@ +# Extended Reference + +Use this reference to sharpen PRD structure around problem, objectives, segments, value proposition, solution, scope, and release planning. + +## Routing Signals + +- create prd +- 8-section prd +- feature spec +- release planning + + +## Purpose + +You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development. + +## Context + +A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders. + +## Instructions + +1. **Gather Information**: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights. + +2. **Think Step by Step**: Before writing, analyze: + - What problem are we solving? + - Who are we solving it for? + - How will we measure success? + - What are our constraints and assumptions? + +3. **Apply the PRD Template**: Create a document with these 8 sections: + + **1. Summary** (2-3 sentences) + - What is this document about? + + **2. Contacts** + - Name, role, and comment for key stakeholders + + **3. Background** + - Context: What is this initiative about? + - Why now? Has something changed? + - Is this something that just recently became possible? + + **4. Objective** + - What's the objective? Why does it matter? + - How will it benefit the company and customers? + - How does it align with vision and strategy? + - Key Results: How will you measure success? (Use SMART OKR format) + + **5. Market Segment(s)** + - For whom are we building this? + - What constraints exist? + - Note: Markets are defined by people's problems/jobs, not demographics + + **6. Value Proposition(s)** + - What customer jobs/needs are we addressing? + - What will customers gain? + - Which pains will they avoid? + - Which problems do we solve better than competitors? + - Consider the Value Curve framework + + **7. Solution** + - 7.1 UX/Prototypes (wireframes, user flows) + - 7.2 Key Features (detailed feature descriptions) + - 7.3 Technology (optional, only if relevant) + - 7.4 Assumptions (what we believe but haven't proven) + + **8. Release** + - How long could it take? + - What goes in the first version vs. future versions? + - Avoid exact dates; use relative timeframes + +4. **Use Accessible Language**: Write for a primary school graduate. Avoid jargon. Use clear, short sentences. + +5. **Structure Output**: Present the PRD as a well-formatted markdown document with clear headings and sections. + +6. **Save the Output**: If the PRD is substantial (which it will be), save it as a markdown document in the format: `PRD-[product-name].md` + +## Notes + +- Be specific and data-driven where possible +- Link each section back to the overall strategy +- Flag assumptions clearly so the team can validate them +- Keep the document concise but complete + +--- + +### Further Reading + +- [How to Write a Product Requirements Document? The Best PRD Template.](https://www.productcompass.pm/p/prd-template) +- [A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)](https://www.productcompass.pm/p/ai-prd-template) diff --git a/.agents/skills/productize-writing-plans/SKILL.md b/skills/productize-writing-plans/SKILL.md similarity index 100% rename from .agents/skills/productize-writing-plans/SKILL.md rename to skills/productize-writing-plans/SKILL.md diff --git a/.agents/skills/productize-writing-plans/agents/openai.yaml b/skills/productize-writing-plans/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-writing-plans/agents/openai.yaml rename to skills/productize-writing-plans/agents/openai.yaml diff --git a/skills/productize-wwas/SKILL.md b/skills/productize-wwas/SKILL.md new file mode 100644 index 00000000..2b13d48a --- /dev/null +++ b/skills/productize-wwas/SKILL.md @@ -0,0 +1,150 @@ +--- +name: productize-wwas +description: >- + Why-What-Acceptance. Use when writing backlog items in Why-What-Acceptance format, breaking + features into independent valuable work, or adding strategic context to delivery items. +--- + + + +# Why-What-Acceptance + +## Productize Preamble + +Before producing the artifact, implementation step, or code change, classify the work: + +- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. +- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. +- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. +- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. +- **Evidence standard**: what is known, assumed, missing, and risky. +- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. + +Operating rules: + +1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. +2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. +3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. +4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. +5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. +6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. +7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. +8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. +9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. +10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. + +Artifact format policy: + +- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. +- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. +- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. +- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. +- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. +- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. + +Runtime hooks, if available: + +- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. +- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. +- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. +- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. +- Use `productize-session-log` to record important workflow decisions. +- Use `productize-artifact-log` when a durable artifact is produced. +- Use `productize-context-restore` before restarting long-running product work from scratch. +- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. +- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. +- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. + +Telemetry standard: + +- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. +- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. + +Current skill metadata: + +- **Skill**: `wwas` +- **Lifecycle**: Plan +- **Category**: Delivery +- **Primary artifact**: Why-What-Acceptance backlog items with strategic context and acceptance criteria + +Use when writing backlog items in Why-What-Acceptance format, breaking features into independent valuable work, or adding strategic context to delivery items. + +## Productize Contract + +- **Primary lifecycle**: Plan +- **Supporting lifecycle**: Build With AI +- **Primary artifact**: Why-What-Acceptance backlog items with strategic context and acceptance criteria +- **Source method**: pm-skills-main/pm-execution/skills/wwas/SKILL.md + +## Method + +Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context. + +**Use when:** Writing backlog items, creating product increments, breaking features into work items, or communicating strategic intent to teams. + +**Arguments:** +- `$PRODUCT`: The product or system name +- `$FEATURE`: The new feature or capability +- `$DESIGN`: Link to design files (Figma, Miro, etc.) +- `$ASSUMPTIONS`: Key assumptions and strategic context + +## Step-by-Step Process + +1. **Define the strategic Why** - Connect work to business and team objectives +2. **Describe the What** - Keep descriptions concise, reference designs +3. **Write Acceptance Criteria** - High-level, not detailed specifications +4. **Ensure independence** - Items can be developed in any order +5. **Keep items negotiable** - Invite team conversation, not constraints +6. **Make items valuable** - Each delivers measurable user or business value +7. **Ensure testability** - Outcomes are observable and verifiable +8. **Size appropriately** - Small enough for one sprint estimate + +## Item Template + +**Title:** [What will be delivered] + +**Why:** [1-2 sentences connecting to strategic context and team objectives] + +**What:** [Short description and design link. 1-2 paragraphs maximum. A reminder of discussion, not detailed specification.] + +**Acceptance Criteria:** +- [Observable outcome 1] +- [Observable outcome 2] +- [Observable outcome 3] +- [Observable outcome 4] + +## Example WWA Item + +**Title:** Implement Real-Time Spending Tracker + +**Why:** Users need immediate feedback on spending to make conscious budget decisions. This directly supports our goal to improve financial awareness and reduce overspending. + +**What:** Add a real-time spending tracker that updates as users log expenses. The tracker displays their current week's spending against their set budget. Designs available in [Figma link]. This is a reminder of our discussions - detailed specifications will emerge during development conversations with the team. + +**Acceptance Criteria:** +- Spending totals update within 2 seconds of logging an expense +- Budget progress is visually indicated with a progress bar +- Users can see remaining budget amount at a glance +- System handles multiple expense categories correctly + +## Output Deliverables + +- Complete set of backlog items for the feature +- Each item includes Why, What, and Acceptance Criteria sections +- Items are independent and deliverable in any order +- Items are sized for estimation and completion in one sprint +- Strategic context is clear for team decision-making +- Design references are included for implementation guidance + +--- + +### Further Reading + +- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories) + +## Productize Output Rules + +- Produce the artifact named in the Productize contract, not a generic framework summary. +- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. +- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. +- If this reference method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/.agents/skills/productize-wwas/agents/openai.yaml b/skills/productize-wwas/agents/openai.yaml similarity index 100% rename from .agents/skills/productize-wwas/agents/openai.yaml rename to skills/productize-wwas/agents/openai.yaml diff --git a/.agents/skills/productize/SKILL.md b/skills/productize/SKILL.md similarity index 100% rename from .agents/skills/productize/SKILL.md rename to skills/productize/SKILL.md diff --git a/.agents/skills/productize/agents/openai.yaml b/skills/productize/agents/openai.yaml similarity index 100% rename from .agents/skills/productize/agents/openai.yaml rename to skills/productize/agents/openai.yaml diff --git a/skills/proto-persona-profiles-from-user-research-and-market-data/SKILL.md b/skills/proto-persona-profiles-from-user-research-and-market-data/SKILL.md deleted file mode 100644 index a65a29dc..00000000 --- a/skills/proto-persona-profiles-from-user-research-and-market-data/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: proto-persona-profiles-from-user-research-and-market-data -description: >- - Proto-persona profiles from user research and market data. Use when the user needs a product - workflow for user research related to proto-persona profiles from user research and market - data. Trigger terms: user-research, personas, ux. ---- - - - -# Proto-persona profiles from user research and market data - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `proto-persona-profiles-from-user-research-and-market-data` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Proto-persona profiles from user research and market data research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Proto-persona profiles from user research and market data**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- `{{USER_RESEARCH}}`: Interview notes, quotes, observations, transcripts. -- `{{MARKET_DATA}}`: Segment size, competitors, market trends. -- `{{BEHAVIORAL_INSIGHTS}}`: Analytics, JTBD signals, usage patterns. -- `{{DEMOGRAPHICS}}`: Age, location, income, education, and related profile context. -- `{{CONSTRAINTS}}` (optional): Industry, region, compliance, accessibility constraints. -- `{{PREFERENCES}}` (optional): `tone`, `depth` (`brief|standard|deep`), `number_of_personas` (default `1`). - - -GOAL -Synthesize mixed research inputs into concise, evidence-linked proto-persona profile(s) ready for early product decisions and validation. -Success metric: -- Persona profiles are internally consistent and clearly distinguish evidence from assumptions. -- Each profile includes confidence, explicit unknowns, and prioritized probing questions. -- Output follows required markdown canvas structure exactly. - -CONSTRAINTS -- Use only provided inputs; if data is missing, write `TBD` and cover it in Probing Questions. -- Extract concrete signals first (quotes, facts, metrics), then synthesize into pains/goals/behaviors. -- Clearly mark each claim as evidence-based or assumption with confidence (`High|Med|Low`). -- Use bracketed source tags (for example: `[UR#3]`, `[GA]`, `[MD]`) wherever evidence is cited. -- Avoid demographic stereotyping; unsupported demographics must be `TBD` or explicit assumptions. -- Ensure behaviors are observable and distinct from goals. -- If `number_of_personas > 1`, output distinct personas. -- Output markdown only; no JSON, XML, or HTML. -- Keep each persona under 400 words unless `depth = deep`. - -FORMAT -- Return one markdown code block per persona. -- Inside each code block, render exactly this structure: - -```markdown -# Proto Persona: {{Alliterative Name}} - -## Bio & Demographics -- Age: {{x-y}}, Location: {{region/city}}, Education: {{...}} -- Role/Status: {{job title or life stage}} -- Income/Spending Power: {{range or TBD}} -- Household/Partner Status: {{...}} -- Digital/Channel Habits: {{top channels/devices}} -- Leisure & Interests: {{...}} -- Notable Constraints: {{time, budget, compliance, accessibility}} - -## Representative Quotes -- "{{quote}}" - [{{source tag}}] -- "{{quote}}" - [{{source tag}}] -- "{{quote}}" - [{{source tag}}] - -## Pains -- {{pain statement}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## What They're Trying to Accomplish (Behaviors & JTBD) -- {{job story or observed behavior}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## Goals -- {{goal}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## Attitudes & Influences -- **Decision-Making Authority:** {{buyer|user|champion|blocker|none}} [{{confidence}}] -- **Decision Influencers:** {{roles/peers/communities}} [{{confidence}}] -- **Beliefs & Attitudes:** {{heuristics, risk posture, trust signals}} [{{confidence}}] - -## Purchasing & Adoption Signals (Optional) -- Triggers: {{events that start the search}} -- Selection Criteria: {{top 3 decision criteria}} -- Objections: {{anticipated blockers}} -- Success Metrics: {{how they judge value}} - -## Accessibility & Inclusion (Optional) -- Considerations: {{access, language, bandwidth, cognitive load}} - -## Evidence & Confidence Summary -- Evidence Sources: {{list with counts, e.g., UR:6, GA:1, MD:2}} -- Assumptions: {{key assumptions}} -- Overall Confidence: {{High|Med|Low}} - {{1-2 sentence rationale}} - -## Probing Questions (Prioritized) -1. {{highest-value unknown}} -2. {{next unknown}} -3. {{next unknown}} -``` - -FAILURE -- Output is not markdown code block(s), or required persona section headings are missing. -- `number_of_personas > 1` is requested but personas are not distinct or separated. -- Quotes/sources do not support key pains, goals, or JTBD claims. -- Claims are untagged (missing evidence/assumption + confidence + source markers). -- `TBD`/low-confidence gaps are not reflected in prioritized probing questions. -- Content exceeds 400 words per persona when `depth` is not `deep`. -- Output includes JSON/XML/HTML or generic filler not grounded in provided inputs. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `user personas`, `proto persona`, `persona from research`, `segment profiles`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/proto-persona-profiles-from-user-research-and-market-data/SKILL.md.tmpl b/skills/proto-persona-profiles-from-user-research-and-market-data/SKILL.md.tmpl deleted file mode 100644 index 5ec123cd..00000000 --- a/skills/proto-persona-profiles-from-user-research-and-market-data/SKILL.md.tmpl +++ /dev/null @@ -1,121 +0,0 @@ ---- -name: proto-persona-profiles-from-user-research-and-market-data -description: >- - Proto-persona profiles from user research and market data. Use when the user needs a product - workflow for user research related to proto-persona profiles from user research and market - data. Trigger terms: user-research, personas, ux. ---- -# Proto-persona profiles from user research and market data - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Proto-persona profiles from user research and market data**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- `{{USER_RESEARCH}}`: Interview notes, quotes, observations, transcripts. -- `{{MARKET_DATA}}`: Segment size, competitors, market trends. -- `{{BEHAVIORAL_INSIGHTS}}`: Analytics, JTBD signals, usage patterns. -- `{{DEMOGRAPHICS}}`: Age, location, income, education, and related profile context. -- `{{CONSTRAINTS}}` (optional): Industry, region, compliance, accessibility constraints. -- `{{PREFERENCES}}` (optional): `tone`, `depth` (`brief|standard|deep`), `number_of_personas` (default `1`). - - -GOAL -Synthesize mixed research inputs into concise, evidence-linked proto-persona profile(s) ready for early product decisions and validation. -Success metric: -- Persona profiles are internally consistent and clearly distinguish evidence from assumptions. -- Each profile includes confidence, explicit unknowns, and prioritized probing questions. -- Output follows required markdown canvas structure exactly. - -CONSTRAINTS -- Use only provided inputs; if data is missing, write `TBD` and cover it in Probing Questions. -- Extract concrete signals first (quotes, facts, metrics), then synthesize into pains/goals/behaviors. -- Clearly mark each claim as evidence-based or assumption with confidence (`High|Med|Low`). -- Use bracketed source tags (for example: `[UR#3]`, `[GA]`, `[MD]`) wherever evidence is cited. -- Avoid demographic stereotyping; unsupported demographics must be `TBD` or explicit assumptions. -- Ensure behaviors are observable and distinct from goals. -- If `number_of_personas > 1`, output distinct personas. -- Output markdown only; no JSON, XML, or HTML. -- Keep each persona under 400 words unless `depth = deep`. - -FORMAT -- Return one markdown code block per persona. -- Inside each code block, render exactly this structure: - -```markdown -# Proto Persona: {{Alliterative Name}} - -## Bio & Demographics -- Age: {{x-y}}, Location: {{region/city}}, Education: {{...}} -- Role/Status: {{job title or life stage}} -- Income/Spending Power: {{range or TBD}} -- Household/Partner Status: {{...}} -- Digital/Channel Habits: {{top channels/devices}} -- Leisure & Interests: {{...}} -- Notable Constraints: {{time, budget, compliance, accessibility}} - -## Representative Quotes -- "{{quote}}" - [{{source tag}}] -- "{{quote}}" - [{{source tag}}] -- "{{quote}}" - [{{source tag}}] - -## Pains -- {{pain statement}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## What They're Trying to Accomplish (Behaviors & JTBD) -- {{job story or observed behavior}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## Goals -- {{goal}} [evidence|assumption, {{confidence}}, {{source|TBD}}] -- {{...}} - -## Attitudes & Influences -- **Decision-Making Authority:** {{buyer|user|champion|blocker|none}} [{{confidence}}] -- **Decision Influencers:** {{roles/peers/communities}} [{{confidence}}] -- **Beliefs & Attitudes:** {{heuristics, risk posture, trust signals}} [{{confidence}}] - -## Purchasing & Adoption Signals (Optional) -- Triggers: {{events that start the search}} -- Selection Criteria: {{top 3 decision criteria}} -- Objections: {{anticipated blockers}} -- Success Metrics: {{how they judge value}} - -## Accessibility & Inclusion (Optional) -- Considerations: {{access, language, bandwidth, cognitive load}} - -## Evidence & Confidence Summary -- Evidence Sources: {{list with counts, e.g., UR:6, GA:1, MD:2}} -- Assumptions: {{key assumptions}} -- Overall Confidence: {{High|Med|Low}} - {{1-2 sentence rationale}} - -## Probing Questions (Prioritized) -1. {{highest-value unknown}} -2. {{next unknown}} -3. {{next unknown}} -``` - -FAILURE -- Output is not markdown code block(s), or required persona section headings are missing. -- `number_of_personas > 1` is requested but personas are not distinct or separated. -- Quotes/sources do not support key pains, goals, or JTBD claims. -- Claims are untagged (missing evidence/assumption + confidence + source markers). -- `TBD`/low-confidence gaps are not reflected in prioritized probing questions. -- Content exceeds 400 words per persona when `depth` is not `deep`. -- Output includes JSON/XML/HTML or generic filler not grounded in provided inputs. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `user personas`, `proto persona`, `persona from research`, `segment profiles`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/proto-persona-profiles-from-user-research-and-market-data/agents/openai.yaml b/skills/proto-persona-profiles-from-user-research-and-market-data/agents/openai.yaml deleted file mode 100644 index c4dd1e44..00000000 --- a/skills/proto-persona-profiles-from-user-research-and-market-data/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Proto-persona profiles from user research and market data" - short_description: "Proto-persona profiles from user research and market data. Use when the user needs a product workflow for user..." - brand_color: "#0D9488" - default_prompt: "Use $proto-persona-profiles-from-user-research-and-market-data with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/proto-persona-profiles-from-user-research-and-market-data/productize.json b/skills/proto-persona-profiles-from-user-research-and-market-data/productize.json deleted file mode 100644 index 7d141528..00000000 --- a/skills/proto-persona-profiles-from-user-research-and-market-data/productize.json +++ /dev/null @@ -1,49 +0,0 @@ -{ - "title": "Proto-persona profiles from user research and market data", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "proto-persona-profiles-from-user-research-and-market-data", - "proto", - "persona", - "profiles", - "research", - "market", - "data", - "user-personas", - "proto-persona", - "persona-from-research", - "segment-profiles" - ], - "use_when": "Proto-persona profiles from user research and market data. Use when the user needs a product workflow for user research related to proto-persona profiles from user research and market data. Trigger terms: user-research, personas, ux.", - "do_not_use_when": "Do not use Proto-persona profiles from user research and market data when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Proto-persona profiles from user research and market data research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "proto-persona-profiles-from-user-research-and-market-data", - "proto", - "persona", - "profiles", - "research", - "market", - "data", - "user-personas", - "proto-persona", - "persona-from-research", - "segment-profiles" - ], - "framework_fit": "Proto-persona profiles from user research and market data fits Discovery work in the Discover lifecycle when the user needs Proto-persona profiles from user research and market data research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Proto-persona profiles from user research and market data research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Proto-persona profiles from user research and market data as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Proto-persona profiles from user research and market data when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $proto-persona-profiles-from-user-research-and-market-data to turn this proto context into a decision-ready Proto-persona profiles from user research and market data research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Proto-persona profiles from user research and market data research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ], - "references": [ - "references/pm-skills-main-merge.md" - ] -} diff --git a/skills/proto-persona-profiles-from-user-research-and-market-data/references/pm-skills-main-merge.md b/skills/proto-persona-profiles-from-user-research-and-market-data/references/pm-skills-main-merge.md deleted file mode 100644 index 35bcc9d0..00000000 --- a/skills/proto-persona-profiles-from-user-research-and-market-data/references/pm-skills-main-merge.md +++ /dev/null @@ -1,75 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to sharpen persona profiles with JTBD, pains, gains, segment traits, unexpected insights, and decision implications. - -## Routing Signals - -- user personas -- proto persona -- persona from research -- segment profiles - -## pm-market-research/skills/user-personas/SKILL.md - -## Purpose -Create detailed, actionable user personas from research data that capture the true diversity of your user base. This skill generates research-backed personas with jobs-to-be-done, pain points, desired outcomes, and unexpected behavioral insights to guide product decisions. - -## Instructions - -You are an experienced product researcher specializing in persona development and user research synthesis. - -### Input -Your task is to create 3 refined user personas for **$ARGUMENTS**. - -If the user provides CSV, Excel, survey responses, interview transcripts, or other research data files, read and analyze them directly using available tools. Extract key patterns, demographics, motivations, and behaviors. - -### Analysis Steps (Think Step by Step) - -1. **Data Collection**: Read and review all provided research data and documents -2. **Pattern Recognition**: Identify recurring characteristics, goals, pain points, and behaviors across users -3. **Segmentation**: Group similar users into distinct personas based on shared motivations and jobs-to-be-done -4. **Enrichment**: For each persona, synthesize data into a coherent profile -5. **Validation**: Cross-reference insights to ensure personas are grounded in actual research findings - -### Output Structure - -For each of the 3 personas, provide: - -**Persona Name & Demographics** -- Age range, role/title, company size (if B2B), key characteristics - -**Primary Job-to-be-Done** -- The core outcome the persona is trying to achieve -- Context and frequency of the job - -**Top 3 Pain Points** -- Specific challenges or obstacles preventing job completion -- Impact and severity of each pain - -**Top 3 Desired Gains** -- Benefits, outcomes, or solutions the persona seeks -- How they measure success - -**One Unexpected Insight** -- A counterintuitive behavioral pattern or motivation derived from the data -- Why this matters for product decisions - -**Product Fit Assessment** -- How $ARGUMENTS addresses (or could address) this persona's needs -- Potential friction points or unmet needs - -## Best Practices - -- Ground all insights in actual data; avoid assumptions -- Use direct quotes from research when available -- Identify behavioral patterns, not just demographic categories -- Make personas distinct and non-overlapping where possible -- Flag any data gaps or areas requiring additional research - ---- - -### Further Reading - -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques) -- [Jobs-to-be-Done Masterclass with Tony Ulwick and Sabeen Sattar](https://www.productcompass.pm/p/jobs-to-be-done-masterclass-with) (video course) diff --git a/skills/prototype-creation-from-image-descriptions-and-app-info/SKILL.md b/skills/prototype-creation-from-image-descriptions-and-app-info/SKILL.md deleted file mode 100644 index dcdcbae7..00000000 --- a/skills/prototype-creation-from-image-descriptions-and-app-info/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: prototype-creation-from-image-descriptions-and-app-info -description: >- - Prototype creation from image descriptions and app info. Use when the user needs a product - workflow for design & prototyping related to prototype creation from image descriptions and - app info. Trigger terms: pm, ux, prototyping, html, interaction-design. ---- - - - -# Prototype creation from image descriptions and app info - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `prototype-creation-from-image-descriptions-and-app-info` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Prototype creation from image descriptions and app info UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Prototype creation from image descriptions and app info**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{IMAGE_DESCRIPTION}} -- {{APP_INFO}} - - -GOAL -Produce a high-quality deliverable for: Prototype creation from image descriptions and app info. -Success metric: -- Produces a coherent clickable screen prototype aligned with provided image/app context. -- Includes complete HTML, CSS, and JavaScript with responsive layout and interactive behavior. -- Returns incremental build artifacts plus a final merged prototype file. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{IMAGE_DESCRIPTION}}` and `{{APP_INFO}}`; if details are missing, state assumptions explicitly. -- Build a realistic screen mental model before coding. -- Provide incremental artifacts in this order: - - `html_structure` - - `css_styles` - - `js_functionality` - - `final_prototype` -- `html_structure` must include ``, ``, ``, ``, and `<body>` scaffolding. -- `css_styles` must include responsive layout rules and clear interactive states. -- `js_functionality` must implement click behavior for primary interactive elements. -- `final_prototype` must combine valid HTML+CSS+JS into one executable file snippet. -- Keep the prototype suitable for user testing: functional, readable, and context-aligned. - -FORMAT -Return exactly this structure: - -<html_structure> -[Basic HTML scaffold only] -</html_structure> - -<css_styles> -[CSS for layout, components, states, and responsiveness] -</css_styles> - -<js_functionality> -[JavaScript for interactions, click handlers, and lightweight transitions] -</js_functionality> - -<final_prototype> -[Single complete HTML file containing merged HTML, CSS, and JS] -</final_prototype> - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, out of order, or incomplete. -- `final_prototype` does not contain a full standalone HTML document. -- Interactive elements are described but not implemented in JavaScript. -- Layout is not responsive or lacks interaction feedback states. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/prototype-creation-from-image-descriptions-and-app-info/SKILL.md.tmpl b/skills/prototype-creation-from-image-descriptions-and-app-info/SKILL.md.tmpl deleted file mode 100644 index 36c0a0ab..00000000 --- a/skills/prototype-creation-from-image-descriptions-and-app-info/SKILL.md.tmpl +++ /dev/null @@ -1,77 +0,0 @@ ---- -name: prototype-creation-from-image-descriptions-and-app-info -description: >- - Prototype creation from image descriptions and app info. Use when the user needs a product - workflow for design & prototyping related to prototype creation from image descriptions and - app info. Trigger terms: pm, ux, prototyping, html, interaction-design. ---- -# Prototype creation from image descriptions and app info - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Prototype creation from image descriptions and app info**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{IMAGE_DESCRIPTION}} -- {{APP_INFO}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Prototype creation from image descriptions and app info. -Success metric: -- Produces a coherent clickable screen prototype aligned with provided image/app context. -- Includes complete HTML, CSS, and JavaScript with responsive layout and interactive behavior. -- Returns incremental build artifacts plus a final merged prototype file. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{IMAGE_DESCRIPTION}}` and `{{APP_INFO}}`; if details are missing, state assumptions explicitly. -- Build a realistic screen mental model before coding. -- Provide incremental artifacts in this order: - - `html_structure` - - `css_styles` - - `js_functionality` - - `final_prototype` -- `html_structure` must include `<!DOCTYPE html>`, `<html>`, `<head>`, `<title>`, and `<body>` scaffolding. -- `css_styles` must include responsive layout rules and clear interactive states. -- `js_functionality` must implement click behavior for primary interactive elements. -- `final_prototype` must combine valid HTML+CSS+JS into one executable file snippet. -- Keep the prototype suitable for user testing: functional, readable, and context-aligned. - -FORMAT -Return exactly this structure: - -<html_structure> -[Basic HTML scaffold only] -</html_structure> - -<css_styles> -[CSS for layout, components, states, and responsiveness] -</css_styles> - -<js_functionality> -[JavaScript for interactions, click handlers, and lightweight transitions] -</js_functionality> - -<final_prototype> -[Single complete HTML file containing merged HTML, CSS, and JS] -</final_prototype> - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, out of order, or incomplete. -- `final_prototype` does not contain a full standalone HTML document. -- Interactive elements are described but not implemented in JavaScript. -- Layout is not responsive or lacks interaction feedback states. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/prototype-creation-from-image-descriptions-and-app-info/agents/openai.yaml b/skills/prototype-creation-from-image-descriptions-and-app-info/agents/openai.yaml deleted file mode 100644 index 7e333d2e..00000000 --- a/skills/prototype-creation-from-image-descriptions-and-app-info/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Prototype creation from image descriptions and app info" - short_description: "Prototype creation from image descriptions and app info. Use when the user needs a product workflow for design &..." - brand_color: "#DB2777" - default_prompt: "Use $prototype-creation-from-image-descriptions-and-app-info with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/prototype-creation-from-image-descriptions-and-app-info/productize.json b/skills/prototype-creation-from-image-descriptions-and-app-info/productize.json deleted file mode 100644 index ed47e544..00000000 --- a/skills/prototype-creation-from-image-descriptions-and-app-info/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Prototype creation from image descriptions and app info", - "category": "Design", - "lifecycle": "Design", - "tags": [ - "prototype-creation-from-image-descriptions-and-app-info", - "prototype", - "creation", - "image", - "descriptions", - "app", - "info" - ], - "use_when": "Prototype creation from image descriptions and app info. Use when the user needs a product workflow for design & prototyping related to prototype creation from image descriptions and app info. Trigger terms: pm, ux, prototyping, html, interaction-design.", - "do_not_use_when": "Do not use Prototype creation from image descriptions and app info when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Prototype creation from image descriptions and app info UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "prototype-creation-from-image-descriptions-and-app-info", - "prototype", - "creation", - "image", - "descriptions", - "app", - "info" - ], - "framework_fit": "Prototype creation from image descriptions and app info fits Design work in the Design lifecycle when the user needs Prototype creation from image descriptions and app info UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Prototype creation from image descriptions and app info UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Prototype creation from image descriptions and app info as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Prototype creation from image descriptions and app info when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $prototype-creation-from-image-descriptions-and-app-info to turn this prototype context into a decision-ready Prototype creation from image descriptions and app info UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Prototype creation from image descriptions and app info UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/pyramid-structure-optimization-from-complex-text/SKILL.md b/skills/pyramid-structure-optimization-from-complex-text/SKILL.md deleted file mode 100644 index 381a936c..00000000 --- a/skills/pyramid-structure-optimization-from-complex-text/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: pyramid-structure-optimization-from-complex-text -description: >- - Pyramid structure optimization from complex text. Use when the user needs a product workflow - for presentation & communication related to pyramid structure optimization from complex - text. Trigger terms: writing, storytelling, presentations, structured-thinking. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Pyramid structure optimization from complex text - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `pyramid-structure-optimization-from-complex-text` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Pyramid structure optimization from complex text stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Pyramid structure optimization from complex text**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{TEXT_TO_OPTIMIZE}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Pyramid structure optimization from complex text. -Success metric: -- Produces a clear Minto-style pyramid with one key message and 2-3 supporting arguments. -- Uses only evidence/details traceable to the source text. -- Improves clarity and concision while preserving core meaning. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TEXT_TO_OPTIMIZE}}`; if key context is missing, state assumptions explicitly. -- Identify exactly one key message. -- Provide 2-3 supporting arguments (no more than 3). -- Attach evidence/details for each argument using source-grounded points only. -- Lead with conclusion first, then grouped support (Minto Pyramid Principle). -- Keep wording concise and structured; avoid unnecessary prose. - -FORMAT -Return exactly this structure: - -<optimized_text> -Key Message: [Insert the main conclusion or recommendation] - -Supporting Arguments: -1. [First main argument] - - [Evidence or detail] - - [Evidence or detail] - -2. [Second main argument] - - [Evidence or detail] - - [Evidence or detail] - -3. [Third main argument (if applicable)] - - [Evidence or detail] - - [Evidence or detail] -</optimized_text> - -<explanation> -[Brief explanation of what was changed and why communication is clearer] -</explanation> - -FAILURE -- `<optimized_text>` or `<explanation>` is missing, malformed, or incomplete. -- More than one key message is provided. -- Fewer than 2 or more than 3 supporting arguments are provided. -- Supporting evidence is generic or not traceable to the source text. -- Structure starts with details instead of the key message. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/pyramid-structure-optimization-from-complex-text/SKILL.md.tmpl b/skills/pyramid-structure-optimization-from-complex-text/SKILL.md.tmpl deleted file mode 100644 index 46e131af..00000000 --- a/skills/pyramid-structure-optimization-from-complex-text/SKILL.md.tmpl +++ /dev/null @@ -1,76 +0,0 @@ ---- -name: pyramid-structure-optimization-from-complex-text -description: >- - Pyramid structure optimization from complex text. Use when the user needs a product workflow - for presentation & communication related to pyramid structure optimization from complex - text. Trigger terms: writing, storytelling, presentations, structured-thinking. ---- -# Pyramid structure optimization from complex text - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Pyramid structure optimization from complex text**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{TEXT_TO_OPTIMIZE}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Pyramid structure optimization from complex text. -Success metric: -- Produces a clear Minto-style pyramid with one key message and 2-3 supporting arguments. -- Uses only evidence/details traceable to the source text. -- Improves clarity and concision while preserving core meaning. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{TEXT_TO_OPTIMIZE}}`; if key context is missing, state assumptions explicitly. -- Identify exactly one key message. -- Provide 2-3 supporting arguments (no more than 3). -- Attach evidence/details for each argument using source-grounded points only. -- Lead with conclusion first, then grouped support (Minto Pyramid Principle). -- Keep wording concise and structured; avoid unnecessary prose. - -FORMAT -Return exactly this structure: - -<optimized_text> -Key Message: [Insert the main conclusion or recommendation] - -Supporting Arguments: -1. [First main argument] - - [Evidence or detail] - - [Evidence or detail] - -2. [Second main argument] - - [Evidence or detail] - - [Evidence or detail] - -3. [Third main argument (if applicable)] - - [Evidence or detail] - - [Evidence or detail] -</optimized_text> - -<explanation> -[Brief explanation of what was changed and why communication is clearer] -</explanation> - -FAILURE -- `<optimized_text>` or `<explanation>` is missing, malformed, or incomplete. -- More than one key message is provided. -- Fewer than 2 or more than 3 supporting arguments are provided. -- Supporting evidence is generic or not traceable to the source text. -- Structure starts with details instead of the key message. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/pyramid-structure-optimization-from-complex-text/agents/openai.yaml b/skills/pyramid-structure-optimization-from-complex-text/agents/openai.yaml deleted file mode 100644 index 1530c505..00000000 --- a/skills/pyramid-structure-optimization-from-complex-text/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Pyramid structure optimization from complex text" - short_description: "Pyramid structure optimization from complex text. Use when the user needs a product workflow for presentation &..." - brand_color: "#0891B2" - default_prompt: "Use $pyramid-structure-optimization-from-complex-text with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/pyramid-structure-optimization-from-complex-text/productize.json b/skills/pyramid-structure-optimization-from-complex-text/productize.json deleted file mode 100644 index a296d9cf..00000000 --- a/skills/pyramid-structure-optimization-from-complex-text/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Pyramid structure optimization from complex text", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "pyramid-structure-optimization-from-complex-text", - "pyramid", - "structure", - "optimization", - "complex", - "text" - ], - "use_when": "Pyramid structure optimization from complex text. Use when the user needs a product workflow for presentation & communication related to pyramid structure optimization from complex text. Trigger terms: writing, storytelling, presentations, structured-thinking.", - "do_not_use_when": "Do not use Pyramid structure optimization from complex text when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Pyramid structure optimization from complex text stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "pyramid-structure-optimization-from-complex-text", - "pyramid", - "structure", - "optimization", - "complex", - "text" - ], - "framework_fit": "Pyramid structure optimization from complex text fits Stakeholder Communication work in the Align lifecycle when the user needs Pyramid structure optimization from complex text stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Pyramid structure optimization from complex text stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Pyramid structure optimization from complex text as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Pyramid structure optimization from complex text when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $pyramid-structure-optimization-from-complex-text to turn this pyramid context into a decision-ready Pyramid structure optimization from complex text stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Pyramid structure optimization from complex text stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/qa/SKILL.md b/skills/qa/SKILL.md deleted file mode 100644 index cedf443d..00000000 --- a/skills/qa/SKILL.md +++ /dev/null @@ -1,220 +0,0 @@ ---- -name: qa -description: >- - QA gate for product behavior, acceptance criteria, evals, regression risk, - evidence quality, and ship readiness. Use when a feature, fix, eval result, or - release candidate needs quality verification before proceeding. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# QA - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `qa` -- **Lifecycle**: Launch & Learn -- **Category**: Delivery -- **Primary artifact**: QA gate report with quality scope, evidence, issues, decision, and next gate - -Use this gate to verify behavior against product expectations. QA owns evidence -quality and ship-readiness risk; it does not replace engineering fixes or release -coordination. - -QA is evidence-first. Do not claim a pass without fresh verification. When the user -asks to fix bugs and the host agent can edit files, run a test -> fix -> re-test -loop. When the user asks for report-only QA, document findings and do not fix. - -## Artifact Format - -Use Markdown for a short pass/fail report. Use self-contained HTML when QA needs a -shareable dashboard with scenario matrix, screenshots, traces, issue severity, -health score, before/after evidence, or release-blocker status. If implementation -notes exist, verify they reflect the final tested behavior. - -## Setup - -1. Detect mode: - - **Quick**: critical paths and high-risk changes only. - - **Standard**: critical, high, and medium issues. - - **Exhaustive**: includes cosmetic, content, accessibility, and edge polish. - - **Regression**: compare against a baseline or previously working behavior. - - **Report-only**: never edit files. -2. Detect target: URL, local app, diff scope, feature spec, eval set, or release - candidate. If the target is a web UI and the request asks to use the product - like a real user, test a URL end-to-end, capture screenshots, or inspect - console errors, route the browser-driven exploratory pass to `$dogfood`. -3. Read product spec, acceptance criteria, test plan, TODOs, prior bug reports, - support themes, and relevant gate outputs. -4. Detect available verification tools: unit/integration/e2e tests, browser, - screenshots, logs, eval runner, analytics, or manual scenario review. -5. If authentication, seed data, or environment setup is missing, state the blocker - and the safest fallback coverage. - -## Baseline Workflow - -### Phase 1: Initialize - -- Record target, mode, scope, assumptions, and excluded surfaces. -- Identify changed files/routes/components when a diff exists. -- Create a scenario matrix before testing. - -### Phase 2: Orient - -- Visit or inspect the primary surfaces. -- Map top navigation, primary tasks, error states, empty states, and data flows. -- Check console/log output if available. - -### Phase 3: Explore - -Test like a real user: - -- happy path -- first-run/empty state -- invalid inputs -- permissions/authentication -- interrupted flow -- stale page/session -- duplicate submission -- slow network or timeout -- mobile/responsive path when UI exists -- accessibility basics: keyboard, focus, labels, contrast cues - -### Phase 4: Verify Acceptance - -For each acceptance criterion or eval: - -| Scenario | Expected | Evidence | Result | Notes | -|---|---|---|---|---| - -Evidence can be command output, test results, browser screenshots, traces, logs, -metrics, or explicit reasoning when runtime execution is unavailable. - -### Phase 5: Document Issues - -Each issue must include: - -- severity: P0/P1/P2/P3 -- category: functional, UX, visual, content, performance, accessibility, data, eval -- repro steps -- expected behavior -- actual behavior -- evidence -- likely owner/gate -- fix recommendation or retest instruction - -Do not report vague findings without repro or evidence. - -## Health Score Rubric - -Score 0-100 with explicit caveats: - -- Functional correctness: 30 -- Critical path completion: 20 -- Data/eval validity: 15 -- UX/accessibility: 15 -- Performance/reliability: 10 -- Content/visual polish: 5 -- Observability/debuggability: 5 - -Any P0 blocks release. Any unresolved P1 requires a conditional pass or block -decision with owner and retest plan. - -## Fix Loop - -If fixing is in scope: - -1. Triage issues by severity and blast radius. -2. Locate source using repo search and existing patterns. -3. Make the smallest safe fix. -4. Add or update a regression test when behavior previously worked or could recur. -5. Re-run the specific scenario. -6. Re-run broader smoke/regression checks if the fix touches shared code. -7. Record before/after evidence. - -Stop and escalate if fixes require product, design, or architecture decisions. - -## Final QA - -Before passing: - -- Re-run all affected critical paths. -- Confirm no new console/test/eval failures in covered scope. -- Confirm docs/release/comms follow-ups are called when behavior changed. -- State exactly what was not tested. - -## Route Internally - -- `$dogfood` for browser-driven exploratory QA of local apps, staging URLs, production URLs, sitemap coverage, screenshots, and console checks -- `$test-scenarios` -- `$verification` -- `$acceptance-criteria-for-ui` -- `$validate-data` -- `$robust-experiment-design-from-goals-and-systems` -- `$ab-test-analysis` -- `$support-tickets-as-actionable-product-improvements` -- `$implementation-notes` when testing reveals spec deviations or unresolved implementation decisions - -## Required Output - -Return: - -1. **Quality Scope**: surfaces, user flows, data paths, and scenarios covered. -2. **Evidence**: fresh verification, screenshots/traces/metrics when available, and caveats. -3. **Scenario Matrix**: scenarios, expected behavior, evidence, result, and notes. -4. **Issues**: severity, category, repro steps, expected behavior, actual behavior, evidence, and owner. -5. **Fix / Retest Log**: fixes applied or recommended, tests added, and before/after evidence. -6. **Health Score**: score, caveats, and release impact. -7. **Decision**: pass, conditional pass, retest, block, or escalate. -8. **Next Gate**: release, docs, comms, eng, design, or product review needed. diff --git a/skills/qa/SKILL.md.tmpl b/skills/qa/SKILL.md.tmpl deleted file mode 100644 index 2de40e63..00000000 --- a/skills/qa/SKILL.md.tmpl +++ /dev/null @@ -1,161 +0,0 @@ ---- -name: qa -description: >- - QA gate for product behavior, acceptance criteria, evals, regression risk, - evidence quality, and ship readiness. Use when a feature, fix, eval result, or - release candidate needs quality verification before proceeding. ---- -# QA - -{{PRODUCTIZE_PREAMBLE}} - -Use this gate to verify behavior against product expectations. QA owns evidence -quality and ship-readiness risk; it does not replace engineering fixes or release -coordination. - -QA is evidence-first. Do not claim a pass without fresh verification. When the user -asks to fix bugs and the host agent can edit files, run a test -> fix -> re-test -loop. When the user asks for report-only QA, document findings and do not fix. - -## Artifact Format - -Use Markdown for a short pass/fail report. Use self-contained HTML when QA needs a -shareable dashboard with scenario matrix, screenshots, traces, issue severity, -health score, before/after evidence, or release-blocker status. If implementation -notes exist, verify they reflect the final tested behavior. - -## Setup - -1. Detect mode: - - **Quick**: critical paths and high-risk changes only. - - **Standard**: critical, high, and medium issues. - - **Exhaustive**: includes cosmetic, content, accessibility, and edge polish. - - **Regression**: compare against a baseline or previously working behavior. - - **Report-only**: never edit files. -2. Detect target: URL, local app, diff scope, feature spec, eval set, or release - candidate. If the target is a web UI and the request asks to use the product - like a real user, test a URL end-to-end, capture screenshots, or inspect - console errors, route the browser-driven exploratory pass to `$dogfood`. -3. Read product spec, acceptance criteria, test plan, TODOs, prior bug reports, - support themes, and relevant gate outputs. -4. Detect available verification tools: unit/integration/e2e tests, browser, - screenshots, logs, eval runner, analytics, or manual scenario review. -5. If authentication, seed data, or environment setup is missing, state the blocker - and the safest fallback coverage. - -## Baseline Workflow - -### Phase 1: Initialize - -- Record target, mode, scope, assumptions, and excluded surfaces. -- Identify changed files/routes/components when a diff exists. -- Create a scenario matrix before testing. - -### Phase 2: Orient - -- Visit or inspect the primary surfaces. -- Map top navigation, primary tasks, error states, empty states, and data flows. -- Check console/log output if available. - -### Phase 3: Explore - -Test like a real user: - -- happy path -- first-run/empty state -- invalid inputs -- permissions/authentication -- interrupted flow -- stale page/session -- duplicate submission -- slow network or timeout -- mobile/responsive path when UI exists -- accessibility basics: keyboard, focus, labels, contrast cues - -### Phase 4: Verify Acceptance - -For each acceptance criterion or eval: - -| Scenario | Expected | Evidence | Result | Notes | -|---|---|---|---|---| - -Evidence can be command output, test results, browser screenshots, traces, logs, -metrics, or explicit reasoning when runtime execution is unavailable. - -### Phase 5: Document Issues - -Each issue must include: - -- severity: P0/P1/P2/P3 -- category: functional, UX, visual, content, performance, accessibility, data, eval -- repro steps -- expected behavior -- actual behavior -- evidence -- likely owner/gate -- fix recommendation or retest instruction - -Do not report vague findings without repro or evidence. - -## Health Score Rubric - -Score 0-100 with explicit caveats: - -- Functional correctness: 30 -- Critical path completion: 20 -- Data/eval validity: 15 -- UX/accessibility: 15 -- Performance/reliability: 10 -- Content/visual polish: 5 -- Observability/debuggability: 5 - -Any P0 blocks release. Any unresolved P1 requires a conditional pass or block -decision with owner and retest plan. - -## Fix Loop - -If fixing is in scope: - -1. Triage issues by severity and blast radius. -2. Locate source using repo search and existing patterns. -3. Make the smallest safe fix. -4. Add or update a regression test when behavior previously worked or could recur. -5. Re-run the specific scenario. -6. Re-run broader smoke/regression checks if the fix touches shared code. -7. Record before/after evidence. - -Stop and escalate if fixes require product, design, or architecture decisions. - -## Final QA - -Before passing: - -- Re-run all affected critical paths. -- Confirm no new console/test/eval failures in covered scope. -- Confirm docs/release/comms follow-ups are called when behavior changed. -- State exactly what was not tested. - -## Route Internally - -- `$dogfood` for browser-driven exploratory QA of local apps, staging URLs, production URLs, sitemap coverage, screenshots, and console checks -- `$test-scenarios` -- `$verification` -- `$acceptance-criteria-for-ui` -- `$validate-data` -- `$robust-experiment-design-from-goals-and-systems` -- `$ab-test-analysis` -- `$support-tickets-as-actionable-product-improvements` -- `$implementation-notes` when testing reveals spec deviations or unresolved implementation decisions - -## Required Output - -Return: - -1. **Quality Scope**: surfaces, user flows, data paths, and scenarios covered. -2. **Evidence**: fresh verification, screenshots/traces/metrics when available, and caveats. -3. **Scenario Matrix**: scenarios, expected behavior, evidence, result, and notes. -4. **Issues**: severity, category, repro steps, expected behavior, actual behavior, evidence, and owner. -5. **Fix / Retest Log**: fixes applied or recommended, tests added, and before/after evidence. -6. **Health Score**: score, caveats, and release impact. -7. **Decision**: pass, conditional pass, retest, block, or escalate. -8. **Next Gate**: release, docs, comms, eng, design, or product review needed. diff --git a/skills/qa/agents/openai.yaml b/skills/qa/agents/openai.yaml deleted file mode 100644 index ca989321..00000000 --- a/skills/qa/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "QA" - short_description: "QA gate for product behavior, acceptance criteria, evals, regression risk, evidence quality, and ship readiness. Use..." - brand_color: "#4F46E5" - default_prompt: "Use $qa with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/qa/productize.json b/skills/qa/productize.json deleted file mode 100644 index fc00c673..00000000 --- a/skills/qa/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "QA", - "category": "Delivery", - "lifecycle": "Launch & Learn", - "tags": [ - "qa", - "reviewer", - "gate", - "entry-point", - "quality-gate", - "test-scenarios", - "verification", - "acceptance-criteria", - "ship-readiness", - "delivery", - "behavior", - "acceptance", - "criteria", - "evals" - ], - "use_when": "Use QA when a feature, fix, eval run, release candidate, or production issue needs quality-gate verification against acceptance criteria, regression risk, user behavior, data evidence, and ship readiness.", - "do_not_use_when": "Do not use QA to define the product thesis, rewrite requirements, design the UI, choose architecture, coordinate release mechanics, write docs, audit DX, or craft stakeholder comms; call those gates separately.", - "output_artifact": "QA gate report with quality scope, evidence, issues, decision, and next gate", - "routing_signals": [ - "qa", - "quality-gate", - "test-this", - "acceptance-criteria", - "verification-evidence", - "regression-risk", - "ship-readiness", - "retest", - "eval-results", - "delivery", - "gate", - "behavior", - "acceptance", - "criteria" - ], - "framework_fit": "QA fits the quality gate before release, after fixes, during eval loops, and in production triage when the team needs fresh evidence that behavior meets product expectations and unresolved issues are understood.", - "failure_modes": [ - "Reports confidence without fresh verification evidence, clear coverage scope, repro steps, severity, and caveats about untested paths.", - "Acts as an engineering or design reviewer rather than verifying observable behavior against acceptance criteria and product expectations.", - "Passes the gate while unresolved issues still need release, docs, comms, product, design, or engineering follow-up." - ], - "examples": [ - { - "prompt": "Use $qa as a quality gate for this release candidate: verify acceptance criteria, regression risk, eval evidence, and ship readiness.", - "expected_artifact": "QA gate report with quality scope, evidence, issues, decision, and next gate" - } - ] -} diff --git a/skills/raw-interview-transcript-cleanup/SKILL.md b/skills/raw-interview-transcript-cleanup/SKILL.md deleted file mode 100644 index 93590d22..00000000 --- a/skills/raw-interview-transcript-cleanup/SKILL.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -name: raw-interview-transcript-cleanup -description: >- - Raw interview transcript cleanup. Use when the user needs a product workflow for user - research related to raw interview transcript cleanup. Trigger terms: user-research, - interviews, transcripts. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Raw interview transcript cleanup - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `raw-interview-transcript-cleanup` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Raw interview transcript cleanup research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Raw interview transcript cleanup**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{RAW_TRANSCRIPT}}`: Raw interview transcript with speaker turns. -</provided_inputs> - -GOAL -Clean a raw interview transcript for readability while preserving original meaning, intent, and speaker voice. -Success metric: -- Transcript is easier to read and remains faithful to original content. -- Speaker labels and conversational flow are preserved. -- Output follows the required schema exactly. - -CONSTRAINTS -- Use only the provided transcript content. -- Make light edits only; do not summarize, reinterpret, or remove meaningful content. -- Remove filler words, false starts, and redundant repetitions only when they do not change meaning. -- Preserve each speaker's voice and tone; avoid over-formalizing casual language. -- Keep original speaker labels at the beginning of each turn (for example: `Interviewer:`, `Interviewee:`). -- Preserve unclear/inaudible markers exactly as given (for example: `[inaudible]`). -- Correct punctuation and capitalization for readability. -- Do not add commentary, analysis, or extra sections. - -FORMAT -Return exactly this structure: - -<edited_transcript> -[Cleaned transcript text with original speaker labels and turn order preserved.] -</edited_transcript> - -FAILURE -- Output is not wrapped in `<edited_transcript>` tags. -- Meaning, intent, or factual content is altered. -- Speaker labels are removed, changed, or inconsistently applied. -- Transcript is over-edited (excessive cuts, paraphrasing, or tone normalization). -- Inaudible/unclear markers from source are removed or rewritten. -- Extra sections, commentary, or metadata are included. diff --git a/skills/raw-interview-transcript-cleanup/SKILL.md.tmpl b/skills/raw-interview-transcript-cleanup/SKILL.md.tmpl deleted file mode 100644 index 81982ef1..00000000 --- a/skills/raw-interview-transcript-cleanup/SKILL.md.tmpl +++ /dev/null @@ -1,59 +0,0 @@ ---- -name: raw-interview-transcript-cleanup -description: >- - Raw interview transcript cleanup. Use when the user needs a product workflow for user - research related to raw interview transcript cleanup. Trigger terms: user-research, - interviews, transcripts. ---- -# Raw interview transcript cleanup - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Raw interview transcript cleanup**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{RAW_TRANSCRIPT}}`: Raw interview transcript with speaker turns. -</provided_inputs> - -GOAL -Clean a raw interview transcript for readability while preserving original meaning, intent, and speaker voice. -Success metric: -- Transcript is easier to read and remains faithful to original content. -- Speaker labels and conversational flow are preserved. -- Output follows the required schema exactly. - -CONSTRAINTS -- Use only the provided transcript content. -- Make light edits only; do not summarize, reinterpret, or remove meaningful content. -- Remove filler words, false starts, and redundant repetitions only when they do not change meaning. -- Preserve each speaker's voice and tone; avoid over-formalizing casual language. -- Keep original speaker labels at the beginning of each turn (for example: `Interviewer:`, `Interviewee:`). -- Preserve unclear/inaudible markers exactly as given (for example: `[inaudible]`). -- Correct punctuation and capitalization for readability. -- Do not add commentary, analysis, or extra sections. - -FORMAT -Return exactly this structure: - -<edited_transcript> -[Cleaned transcript text with original speaker labels and turn order preserved.] -</edited_transcript> - -FAILURE -- Output is not wrapped in `<edited_transcript>` tags. -- Meaning, intent, or factual content is altered. -- Speaker labels are removed, changed, or inconsistently applied. -- Transcript is over-edited (excessive cuts, paraphrasing, or tone normalization). -- Inaudible/unclear markers from source are removed or rewritten. -- Extra sections, commentary, or metadata are included. diff --git a/skills/raw-interview-transcript-cleanup/agents/openai.yaml b/skills/raw-interview-transcript-cleanup/agents/openai.yaml deleted file mode 100644 index e0983841..00000000 --- a/skills/raw-interview-transcript-cleanup/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Raw interview transcript cleanup" - short_description: "Raw interview transcript cleanup. Use when the user needs a product workflow for user research related to raw..." - brand_color: "#0D9488" - default_prompt: "Use $raw-interview-transcript-cleanup with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/raw-interview-transcript-cleanup/productize.json b/skills/raw-interview-transcript-cleanup/productize.json deleted file mode 100644 index d256eb79..00000000 --- a/skills/raw-interview-transcript-cleanup/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Raw interview transcript cleanup", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "raw-interview-transcript-cleanup", - "raw", - "interview", - "transcript", - "cleanup", - "research", - "discovery" - ], - "use_when": "Raw interview transcript cleanup. Use when the user needs a product workflow for user research related to raw interview transcript cleanup. Trigger terms: user-research, interviews, transcripts.", - "do_not_use_when": "Do not use Raw interview transcript cleanup when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Raw interview transcript cleanup research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "raw-interview-transcript-cleanup", - "raw", - "interview", - "transcript", - "cleanup", - "research", - "discovery" - ], - "framework_fit": "Raw interview transcript cleanup fits Discovery work in the Discover lifecycle when the user needs Raw interview transcript cleanup research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Raw interview transcript cleanup research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Raw interview transcript cleanup as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Raw interview transcript cleanup when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $raw-interview-transcript-cleanup to turn this raw context into a decision-ready Raw interview transcript cleanup research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Raw interview transcript cleanup research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/realistic-jtbd-interview-transcripts/SKILL.md b/skills/realistic-jtbd-interview-transcripts/SKILL.md deleted file mode 100644 index fbdbe4fd..00000000 --- a/skills/realistic-jtbd-interview-transcripts/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: realistic-jtbd-interview-transcripts -description: >- - Realistic JTBD interview transcripts. Use when the user needs a product workflow for user - research related to realistic jtbd interview transcripts. Trigger terms: user-research, - jtbd, interviews. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Realistic JTBD interview transcripts - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `realistic-jtbd-interview-transcripts` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Realistic JTBD interview transcripts research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Realistic JTBD interview transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{PRODUCT_TYPE}}`: Product category to explore. -- `{{TARGET_AUDIENCE}}`: Core audience profile for the interview. -- `{{NUM_PARTICIPANTS}}`: Number of participants to include in the transcript. -</provided_inputs> - -GOAL -Generate a realistic multi-participant JTBD interview transcript that surfaces the four forces of progress (push, pull, anxiety, habit) through natural conversation. -Success metric: -- Transcript is realistic, exploratory, and participant-driven. -- Conversation captures current behaviors, pain points, desired outcomes, switching concerns, and habits. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if details are missing, state assumptions briefly in the handover. -- Role-play both Product Designer and participants in a realistic dialogue. -- Product Designer behavior must be: -- Open-ended questioning. -- Follow-up on ambiguity and interesting signals. -- Encouraging elaboration. -- Non-leading and solution-neutral. -- Curious and empathetic tone. -- Cover these conversation phases naturally: -1. Introduction and warm-up. -2. Current solutions and pain points. -3. Desired outcomes and aspirations. -4. Concerns and hesitations about change. -5. Existing routines and habitual behaviors. -- Ensure all participants contribute meaningfully. -- Reveal the four JTBD forces implicitly through content, without naming them explicitly. - -FORMAT -Return exactly this structure: - -<transcript> -Product Designer: [Introduction and first question] - -Participant 1: [Response] - -Product Designer: [Follow-up question] - -Participant 2: [Response] - -[Continue until all participants contribute and the conversation feels complete.] -</transcript> - -<handover> -This concludes the interview transcript. What specific aspects of the conversation would you like me to elaborate on or analyze further? -</handover> - -FAILURE -- Output is missing either `<transcript>` or `<handover>`. -- Transcript does not include the Product Designer plus the requested number of participants. -- Conversation is generic, shallow, or fails to cover required interview phases. -- Product Designer asks leading/solution-prescriptive questions. -- Four JTBD force signals are not inferable from the dialogue. -- Participants do not contribute meaningfully or are not differentiated. -- Assumptions are required but not explicitly noted in handover. diff --git a/skills/realistic-jtbd-interview-transcripts/SKILL.md.tmpl b/skills/realistic-jtbd-interview-transcripts/SKILL.md.tmpl deleted file mode 100644 index 82a26b02..00000000 --- a/skills/realistic-jtbd-interview-transcripts/SKILL.md.tmpl +++ /dev/null @@ -1,82 +0,0 @@ ---- -name: realistic-jtbd-interview-transcripts -description: >- - Realistic JTBD interview transcripts. Use when the user needs a product workflow for user - research related to realistic jtbd interview transcripts. Trigger terms: user-research, - jtbd, interviews. ---- -# Realistic JTBD interview transcripts - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Realistic JTBD interview transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{PRODUCT_TYPE}}`: Product category to explore. -- `{{TARGET_AUDIENCE}}`: Core audience profile for the interview. -- `{{NUM_PARTICIPANTS}}`: Number of participants to include in the transcript. -</provided_inputs> - -GOAL -Generate a realistic multi-participant JTBD interview transcript that surfaces the four forces of progress (push, pull, anxiety, habit) through natural conversation. -Success metric: -- Transcript is realistic, exploratory, and participant-driven. -- Conversation captures current behaviors, pain points, desired outcomes, switching concerns, and habits. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if details are missing, state assumptions briefly in the handover. -- Role-play both Product Designer and participants in a realistic dialogue. -- Product Designer behavior must be: -- Open-ended questioning. -- Follow-up on ambiguity and interesting signals. -- Encouraging elaboration. -- Non-leading and solution-neutral. -- Curious and empathetic tone. -- Cover these conversation phases naturally: -1. Introduction and warm-up. -2. Current solutions and pain points. -3. Desired outcomes and aspirations. -4. Concerns and hesitations about change. -5. Existing routines and habitual behaviors. -- Ensure all participants contribute meaningfully. -- Reveal the four JTBD forces implicitly through content, without naming them explicitly. - -FORMAT -Return exactly this structure: - -<transcript> -Product Designer: [Introduction and first question] - -Participant 1: [Response] - -Product Designer: [Follow-up question] - -Participant 2: [Response] - -[Continue until all participants contribute and the conversation feels complete.] -</transcript> - -<handover> -This concludes the interview transcript. What specific aspects of the conversation would you like me to elaborate on or analyze further? -</handover> - -FAILURE -- Output is missing either `<transcript>` or `<handover>`. -- Transcript does not include the Product Designer plus the requested number of participants. -- Conversation is generic, shallow, or fails to cover required interview phases. -- Product Designer asks leading/solution-prescriptive questions. -- Four JTBD force signals are not inferable from the dialogue. -- Participants do not contribute meaningfully or are not differentiated. -- Assumptions are required but not explicitly noted in handover. diff --git a/skills/realistic-jtbd-interview-transcripts/agents/openai.yaml b/skills/realistic-jtbd-interview-transcripts/agents/openai.yaml deleted file mode 100644 index 602b023d..00000000 --- a/skills/realistic-jtbd-interview-transcripts/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Realistic JTBD interview transcripts" - short_description: "Realistic JTBD interview transcripts. Use when the user needs a product workflow for user research related to..." - brand_color: "#0D9488" - default_prompt: "Use $realistic-jtbd-interview-transcripts with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/realistic-jtbd-interview-transcripts/productize.json b/skills/realistic-jtbd-interview-transcripts/productize.json deleted file mode 100644 index 9b1b36d0..00000000 --- a/skills/realistic-jtbd-interview-transcripts/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Realistic JTBD interview transcripts", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "realistic-jtbd-interview-transcripts", - "realistic", - "jtbd", - "interview", - "transcripts", - "research", - "discovery" - ], - "use_when": "Realistic JTBD interview transcripts. Use when the user needs a product workflow for user research related to realistic jtbd interview transcripts. Trigger terms: user-research, jtbd, interviews.", - "do_not_use_when": "Do not use Realistic JTBD interview transcripts when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Realistic JTBD interview transcripts research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "realistic-jtbd-interview-transcripts", - "realistic", - "jtbd", - "interview", - "transcripts", - "research", - "discovery" - ], - "framework_fit": "Realistic JTBD interview transcripts fits Discovery work in the Discover lifecycle when the user needs Realistic JTBD interview transcripts research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Realistic JTBD interview transcripts research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Realistic JTBD interview transcripts as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Realistic JTBD interview transcripts when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $realistic-jtbd-interview-transcripts to turn this realistic context into a decision-ready Realistic JTBD interview transcripts research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Realistic JTBD interview transcripts research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/reinforcing-sequence-from-unstructured-items/SKILL.md b/skills/reinforcing-sequence-from-unstructured-items/SKILL.md deleted file mode 100644 index 0ae7dcac..00000000 --- a/skills/reinforcing-sequence-from-unstructured-items/SKILL.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -name: reinforcing-sequence-from-unstructured-items -description: >- - Reinforcing sequence from unstructured items. Use when the user needs a product workflow for - project management related to reinforcing sequence from unstructured items. Trigger terms: - systems-thinking, prioritization, root-cause-analysis, workflows. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Reinforcing sequence from unstructured items - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `reinforcing-sequence-from-unstructured-items` -- **Lifecycle**: Think -- **Category**: Operations -- **Primary artifact**: Reinforcing sequence from unstructured items product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Reinforcing sequence from unstructured items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{ITEMS}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Reinforcing sequence from unstructured items. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{ITEMS}}` to build an interrelationship sequence where each step reinforces or enables the next. -- Identify cause-effect links, dependencies, and likely root-driver items. -- Choose a strong starting item and produce one coherent sequence (domino logic). -- Use interrelationship-diagram thinking (drivers vs outcomes, direction of influence, dependency strength) to justify order. -- Include concise reasoning in `<reasoning>` and final ordered list in `<best>`. - -FORMAT -Return exactly this structure: - -<reasoning> -[Concise explanation of key dependencies, reinforcing relationships, starting-point choice, and ordering logic] -</reasoning> - -<best> -[Numbered list of all items from `{{ITEMS}}` in the recommended reinforcing order; one item per line] -</best> - -FAILURE -- `<reasoning>` or `<best>` is missing, malformed, or materially incomplete. -- Final sequence does not include all input items exactly once. -- Ordering is not justified by dependency/reinforcement logic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/reinforcing-sequence-from-unstructured-items/SKILL.md.tmpl b/skills/reinforcing-sequence-from-unstructured-items/SKILL.md.tmpl deleted file mode 100644 index 1568b6f0..00000000 --- a/skills/reinforcing-sequence-from-unstructured-items/SKILL.md.tmpl +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: reinforcing-sequence-from-unstructured-items -description: >- - Reinforcing sequence from unstructured items. Use when the user needs a product workflow for - project management related to reinforcing sequence from unstructured items. Trigger terms: - systems-thinking, prioritization, root-cause-analysis, workflows. ---- -# Reinforcing sequence from unstructured items - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Reinforcing sequence from unstructured items**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{ITEMS}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Reinforcing sequence from unstructured items. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{ITEMS}}` to build an interrelationship sequence where each step reinforces or enables the next. -- Identify cause-effect links, dependencies, and likely root-driver items. -- Choose a strong starting item and produce one coherent sequence (domino logic). -- Use interrelationship-diagram thinking (drivers vs outcomes, direction of influence, dependency strength) to justify order. -- Include concise reasoning in `<reasoning>` and final ordered list in `<best>`. - -FORMAT -Return exactly this structure: - -<reasoning> -[Concise explanation of key dependencies, reinforcing relationships, starting-point choice, and ordering logic] -</reasoning> - -<best> -[Numbered list of all items from `{{ITEMS}}` in the recommended reinforcing order; one item per line] -</best> - -FAILURE -- `<reasoning>` or `<best>` is missing, malformed, or materially incomplete. -- Final sequence does not include all input items exactly once. -- Ordering is not justified by dependency/reinforcement logic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/reinforcing-sequence-from-unstructured-items/agents/openai.yaml b/skills/reinforcing-sequence-from-unstructured-items/agents/openai.yaml deleted file mode 100644 index bbaea3de..00000000 --- a/skills/reinforcing-sequence-from-unstructured-items/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Reinforcing sequence from unstructured items" - short_description: "Reinforcing sequence from unstructured items. Use when the user needs a product workflow for project management..." - brand_color: "#7C3AED" - default_prompt: "Use $reinforcing-sequence-from-unstructured-items with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/reinforcing-sequence-from-unstructured-items/productize.json b/skills/reinforcing-sequence-from-unstructured-items/productize.json deleted file mode 100644 index 08c8a866..00000000 --- a/skills/reinforcing-sequence-from-unstructured-items/productize.json +++ /dev/null @@ -1,40 +0,0 @@ -{ - "title": "Reinforcing sequence from unstructured items", - "category": "Operations", - "lifecycle": "Think", - "tags": [ - "reinforcing-sequence-from-unstructured-items", - "reinforcing", - "sequence", - "unstructured", - "items", - "project", - "management", - "operations" - ], - "use_when": "Reinforcing sequence from unstructured items. Use when the user needs a product workflow for project management related to reinforcing sequence from unstructured items. Trigger terms: systems-thinking, prioritization, root-cause-analysis, workflows.", - "do_not_use_when": "Do not use Reinforcing sequence from unstructured items when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Reinforcing sequence from unstructured items product artifact with evidence, risks, recommendation, and next action", - "routing_signals": [ - "reinforcing-sequence-from-unstructured-items", - "reinforcing", - "sequence", - "unstructured", - "items", - "project", - "management", - "operations" - ], - "framework_fit": "Reinforcing sequence from unstructured items fits Operations work in the Think lifecycle when the user needs Reinforcing sequence from unstructured items product artifact with evidence, risks, recommendation, and next action and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Reinforcing sequence from unstructured items product artifact with evidence, risks, recommendation, and next action without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Reinforcing sequence from unstructured items as generic Operations advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Reinforcing sequence from unstructured items when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $reinforcing-sequence-from-unstructured-items to turn this reinforcing context into a decision-ready Reinforcing sequence from unstructured items product artifact with evidence, risks, recommendation, and next action.", - "expected_artifact": "Reinforcing sequence from unstructured items product artifact with evidence, risks, recommendation, and next action" - } - ] -} diff --git a/skills/release-notes/SKILL.md b/skills/release-notes/SKILL.md deleted file mode 100644 index 100352a4..00000000 --- a/skills/release-notes/SKILL.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -name: release-notes -description: >- - Release Notes. Use when turning tickets, PRDs, changelogs, or shipped work into clear - user-facing release notes or product update copy. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Release Notes - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `release-notes` -- **Lifecycle**: Launch & Learn -- **Category**: Delivery -- **Primary artifact**: Release Notes launch learning report with release evidence, feedback, decision, and next iteration - -Use when turning tickets, PRDs, changelogs, or shipped work into clear user-facing release notes or product update copy. - -## Productize Contract - -- **Primary lifecycle**: Launch & Learn -- **Supporting lifecycle**: Align -- **Primary artifact**: User-facing release notes organized by features, improvements, fixes, and user value -- **Source method**: pm-skills-main/pm-execution/skills/release-notes/SKILL.md - -## Method - -## Release Notes Generator - -Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes. - -### Context - -You are writing release notes for **$ARGUMENTS**. - -If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience. - -### Instructions - -1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract: - - What changed (feature, improvement, or fix) - - Who it affects (which user segment) - - Why it matters (the user benefit) - -2. **Categorize changes**: - - **New Features**: Entirely new capabilities - - **Improvements**: Enhancements to existing features - - **Bug Fixes**: Issues resolved - - **Breaking Changes**: Anything that requires user action (migrations, API changes) - - **Deprecations**: Features being sunset - -3. **Write each entry** following these principles: - - Lead with the user benefit, not the technical change - - Use plain language -- avoid jargon, internal codenames, or ticket numbers - - Keep each entry to 1-3 sentences - - Include visuals or screenshots if the user provides them - - **Example transformations**: - - Technical: "Implemented Redis caching layer for dashboard API endpoints" - - User-facing: "Dashboards now load up to 3x faster, so you spend less time waiting and more time analyzing." - - - Technical: "Fixed race condition in concurrent checkout flow" - - User-facing: "Fixed an issue where some orders could fail during high-traffic periods." - -4. **Structure the release notes**: - - ``` - # [Product Name] -- [Version / Date] - - ## New Features - - **[Feature name]**: [1-2 sentence description of what it does and why it matters] - - ## Improvements - - **[Area]**: [What got better and how it helps] - - ## Bug Fixes - - Fixed [issue description in user terms] - - ## Breaking Changes (if any) - - **Action required**: [What users need to do] - ``` - -5. **Adjust tone** to match the product's voice -- professional for B2B, friendly for consumer, developer-focused for APIs. - -Save as a markdown document. If the user wants HTML or another format, convert accordingly. - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/release-notes/SKILL.md.tmpl b/skills/release-notes/SKILL.md.tmpl deleted file mode 100644 index d15a8910..00000000 --- a/skills/release-notes/SKILL.md.tmpl +++ /dev/null @@ -1,86 +0,0 @@ ---- -name: release-notes -description: >- - Release Notes. Use when turning tickets, PRDs, changelogs, or shipped work into clear - user-facing release notes or product update copy. ---- -# Release Notes - -{{PRODUCTIZE_PREAMBLE}} - -Use when turning tickets, PRDs, changelogs, or shipped work into clear user-facing release notes or product update copy. - -## Productize Contract - -- **Primary lifecycle**: Launch & Learn -- **Supporting lifecycle**: Align -- **Primary artifact**: User-facing release notes organized by features, improvements, fixes, and user value -- **Source method**: pm-skills-main/pm-execution/skills/release-notes/SKILL.md - -## Method - -## Release Notes Generator - -Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes. - -### Context - -You are writing release notes for **$ARGUMENTS**. - -If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience. - -### Instructions - -1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract: - - What changed (feature, improvement, or fix) - - Who it affects (which user segment) - - Why it matters (the user benefit) - -2. **Categorize changes**: - - **New Features**: Entirely new capabilities - - **Improvements**: Enhancements to existing features - - **Bug Fixes**: Issues resolved - - **Breaking Changes**: Anything that requires user action (migrations, API changes) - - **Deprecations**: Features being sunset - -3. **Write each entry** following these principles: - - Lead with the user benefit, not the technical change - - Use plain language -- avoid jargon, internal codenames, or ticket numbers - - Keep each entry to 1-3 sentences - - Include visuals or screenshots if the user provides them - - **Example transformations**: - - Technical: "Implemented Redis caching layer for dashboard API endpoints" - - User-facing: "Dashboards now load up to 3x faster, so you spend less time waiting and more time analyzing." - - - Technical: "Fixed race condition in concurrent checkout flow" - - User-facing: "Fixed an issue where some orders could fail during high-traffic periods." - -4. **Structure the release notes**: - - ``` - # [Product Name] -- [Version / Date] - - ## New Features - - **[Feature name]**: [1-2 sentence description of what it does and why it matters] - - ## Improvements - - **[Area]**: [What got better and how it helps] - - ## Bug Fixes - - Fixed [issue description in user terms] - - ## Breaking Changes (if any) - - **Action required**: [What users need to do] - ``` - -5. **Adjust tone** to match the product's voice -- professional for B2B, friendly for consumer, developer-focused for APIs. - -Save as a markdown document. If the user wants HTML or another format, convert accordingly. - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/release-notes/agents/openai.yaml b/skills/release-notes/agents/openai.yaml deleted file mode 100644 index b1af92d4..00000000 --- a/skills/release-notes/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Release Notes" - short_description: "Release Notes. Use when turning tickets, PRDs, changelogs, or shipped work into clear user-facing release notes or..." - brand_color: "#4F46E5" - default_prompt: "Use $release-notes with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/release-notes/productize.json b/skills/release-notes/productize.json deleted file mode 100644 index b804b16c..00000000 --- a/skills/release-notes/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Release Notes", - "category": "Delivery", - "lifecycle": "Launch & Learn", - "tags": [ - "release-notes", - "changelog", - "launch-comms", - "product-update", - "customer-communication", - "align", - "release", - "notes", - "presentation", - "communication", - "use", - "turning", - "delivery", - "tickets" - ], - "use_when": "Use when turning tickets, PRDs, changelogs, or shipped work into clear user-facing release notes or product update copy.", - "do_not_use_when": "Do not use for internal launch readiness, technical changelog generation, or executive status updates.", - "output_artifact": "Release Notes launch learning report with release evidence, feedback, decision, and next iteration", - "routing_signals": [ - "release-notes", - "changelog", - "launch-comms", - "product-update", - "customer-communication", - "when", - "turning", - "tickets", - "prds", - "changelogs", - "shipped", - "work", - "into", - "clear" - ], - "framework_fit": "Best after shipping or preparing to ship when the audience needs concise value-oriented communication about what changed.", - "failure_modes": [ - "Produces Release Notes launch learning report with release evidence, feedback, decision, and next iteration without tying recommendations to the user's Launch & Learn stage, evidence, and decision pressure.", - "Treats Release Notes as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Release Notes when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $release-notes to turn this changelog context into a decision-ready Release Notes launch learning report with release evidence, feedback, decision, and next iteration.", - "expected_artifact": "Release Notes launch learning report with release evidence, feedback, decision, and next iteration" - } - ], - "imported_from": "pm-skills-main/pm-execution/skills/release-notes/SKILL.md" -} diff --git a/skills/release/SKILL.md b/skills/release/SKILL.md deleted file mode 100644 index 57bc830d..00000000 --- a/skills/release/SKILL.md +++ /dev/null @@ -1,207 +0,0 @@ ---- -name: release -description: >- - Release gate for ship readiness, deployment decision, changelog needs, rollback - risk, versioning, launch coordination, and post-release learning. Use when work - is moving from build or QA toward production. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Release - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `release` -- **Lifecycle**: Launch & Learn -- **Category**: Delivery -- **Primary artifact**: Release readiness report with scope, evidence, gate status, release decision, and post-release loop - -Use this gate to decide whether to ship, hold, split, rollback, or prepare a launch -sequence. Release owns coordination across QA, docs, comms, and operating handoff. - -Release is the go/no-go workflow. It does not mean "write release notes." It checks -whether the change is safe, reviewed, tested, documented, communicable, observable, -and reversible enough to reach production. - -## Artifact Format - -Use Markdown for a small release call. Use self-contained HTML when the release -decision needs a readiness dashboard, gate matrix, rollout/rollback visualization, -scope completion audit, verification evidence, or a shareable ship/hold artifact. -If implementation notes exist, include them as release evidence and flag stale or -unresolved entries. - -## Pre-Flight - -1. Detect platform, branch/base, deployment path, release artifact, and current - production state when a repo exists. -2. Read the plan, diff, changelog, tests, QA evidence, prior gates, TODOs, and docs. -3. Identify changed user surfaces, data migrations, config/env changes, API/SDK - changes, pricing/comms changes, and operational risks. -4. Mark stale gate outputs if the commit/scope changed since they ran. -5. Name the release decision: ship, hold, split, stage, rollback, or hotfix. - -## Review Readiness Dashboard - -Produce a dashboard before deciding: - -| Gate | Status | Evidence | Required? | Stale? | -|---|---|---|---|---| -| Thesis | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Product | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Design | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Eng | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| QA | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Docs | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| DX | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Comms | clear / missing / stale / not needed | artifact | yes/no | yes/no | - -Missing required gates block release unless the user explicitly accepts the risk. - -## Release Workflow - -### 1. Merge/Base Freshness - -- Confirm whether the work is based on the intended release branch. -- If the base changed, state whether tests/QA need to be rerun. -- Do not hide merge conflicts, dependency changes, or drift from prior reviews. - -### 2. Test And Eval Evidence - -- Summarize test commands, eval suites, browser/manual QA, and coverage gaps. -- When the product has a web UI, treat `$dogfood` output as release evidence: - pages tested, flows tested, console errors, screenshots/evidence, severity - table, blockers, and release impact. -- Classify failures as in-scope, pre-existing, environment, flaky, or unknown. -- In-scope failures block unless explicitly accepted with rollback/mitigation. - -### 3. Scope Completion Audit - -Cross-reference the plan against what changed: - -| Planned item | Evidence in diff/release | Status | -|---|---|---| - -Classify items as implemented, intentionally deferred, missing, or no longer -relevant. Missing P0 items block release. - -### 4. Scope Drift Detection - -- What changed beyond the plan? -- Does the drift add product, design, engineering, QA, docs, DX, or comms risk? -- Should the release split? - -### 5. Rollout And Rollback - -Require: - -- deployment steps -- migration/feature flag posture -- monitoring and alerting -- rollback/revert path -- owner during and after release -- customer/support impact - -### 6. Docs, DX, And Comms - -- Docs gate is required when behavior, setup, API, migration, or support guidance changes. -- DX gate is required when developers integrate, install, migrate, or debug the change. -- Comms gate is required for customer-facing, stakeholder-facing, pricing, or launch messages. - -### 7. Post-Release Operate Handoff - -Define the first operate-loop check: - -- metric or signal -- support/feedback watch -- review time -- owner -- trigger for rollback, fix, growth, or new `$0-1` loop - -## Decision Protocol - -Use release decisions precisely: - -- **Ship**: all required gates clear and rollback/monitoring are acceptable. -- **Conditional ship**: risks are known, owner accepts them, and rollback/monitoring are explicit. -- **Hold**: missing required evidence or unresolved P0/P1 risk. -- **Split**: safe subset can ship while risky scope waits. -- **Stage**: ship behind flag, cohort, or internal-only rollout. -- **Rollback/hotfix**: production behavior is already harmful. - -## Route Internally - -- `$pre-mortem` -- `$release-notes` -- `$post-launch-feedback-loop` -- `$metrics-review` -- `$verification` -- `$qa` -- `$dogfood` when a web UI needs browser-driven release evidence -- `$docs` -- `$comms-review` -- `$implementation-notes` - -## Required Output - -Return: - -1. **Release Scope**: changes, affected users, dependencies, and version/changelog needs. -2. **Readiness Evidence**: tests, QA result, known risks, rollback path, and monitoring. -3. **Review Readiness Dashboard**: gate status, evidence, required/missing/stale calls. -4. **Completion Audit**: planned items, implemented evidence, missing work, and drift. -5. **Rollout Plan**: deploy, monitor, rollback, support, and owner. -6. **Decision**: ship, conditional ship, hold, split, rollback, hotfix, or stage. -7. **Post-Release Loop**: owner, metric, feedback path, review time, and next operate/grow trigger. diff --git a/skills/release/SKILL.md.tmpl b/skills/release/SKILL.md.tmpl deleted file mode 100644 index 6b9e2eee..00000000 --- a/skills/release/SKILL.md.tmpl +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: release -description: >- - Release gate for ship readiness, deployment decision, changelog needs, rollback - risk, versioning, launch coordination, and post-release learning. Use when work - is moving from build or QA toward production. ---- -# Release - -{{PRODUCTIZE_PREAMBLE}} - -Use this gate to decide whether to ship, hold, split, rollback, or prepare a launch -sequence. Release owns coordination across QA, docs, comms, and operating handoff. - -Release is the go/no-go workflow. It does not mean "write release notes." It checks -whether the change is safe, reviewed, tested, documented, communicable, observable, -and reversible enough to reach production. - -## Artifact Format - -Use Markdown for a small release call. Use self-contained HTML when the release -decision needs a readiness dashboard, gate matrix, rollout/rollback visualization, -scope completion audit, verification evidence, or a shareable ship/hold artifact. -If implementation notes exist, include them as release evidence and flag stale or -unresolved entries. - -## Pre-Flight - -1. Detect platform, branch/base, deployment path, release artifact, and current - production state when a repo exists. -2. Read the plan, diff, changelog, tests, QA evidence, prior gates, TODOs, and docs. -3. Identify changed user surfaces, data migrations, config/env changes, API/SDK - changes, pricing/comms changes, and operational risks. -4. Mark stale gate outputs if the commit/scope changed since they ran. -5. Name the release decision: ship, hold, split, stage, rollback, or hotfix. - -## Review Readiness Dashboard - -Produce a dashboard before deciding: - -| Gate | Status | Evidence | Required? | Stale? | -|---|---|---|---|---| -| Thesis | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Product | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Design | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Eng | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| QA | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Docs | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| DX | clear / missing / stale / not needed | artifact | yes/no | yes/no | -| Comms | clear / missing / stale / not needed | artifact | yes/no | yes/no | - -Missing required gates block release unless the user explicitly accepts the risk. - -## Release Workflow - -### 1. Merge/Base Freshness - -- Confirm whether the work is based on the intended release branch. -- If the base changed, state whether tests/QA need to be rerun. -- Do not hide merge conflicts, dependency changes, or drift from prior reviews. - -### 2. Test And Eval Evidence - -- Summarize test commands, eval suites, browser/manual QA, and coverage gaps. -- When the product has a web UI, treat `$dogfood` output as release evidence: - pages tested, flows tested, console errors, screenshots/evidence, severity - table, blockers, and release impact. -- Classify failures as in-scope, pre-existing, environment, flaky, or unknown. -- In-scope failures block unless explicitly accepted with rollback/mitigation. - -### 3. Scope Completion Audit - -Cross-reference the plan against what changed: - -| Planned item | Evidence in diff/release | Status | -|---|---|---| - -Classify items as implemented, intentionally deferred, missing, or no longer -relevant. Missing P0 items block release. - -### 4. Scope Drift Detection - -- What changed beyond the plan? -- Does the drift add product, design, engineering, QA, docs, DX, or comms risk? -- Should the release split? - -### 5. Rollout And Rollback - -Require: - -- deployment steps -- migration/feature flag posture -- monitoring and alerting -- rollback/revert path -- owner during and after release -- customer/support impact - -### 6. Docs, DX, And Comms - -- Docs gate is required when behavior, setup, API, migration, or support guidance changes. -- DX gate is required when developers integrate, install, migrate, or debug the change. -- Comms gate is required for customer-facing, stakeholder-facing, pricing, or launch messages. - -### 7. Post-Release Operate Handoff - -Define the first operate-loop check: - -- metric or signal -- support/feedback watch -- review time -- owner -- trigger for rollback, fix, growth, or new `$0-1` loop - -## Decision Protocol - -Use release decisions precisely: - -- **Ship**: all required gates clear and rollback/monitoring are acceptable. -- **Conditional ship**: risks are known, owner accepts them, and rollback/monitoring are explicit. -- **Hold**: missing required evidence or unresolved P0/P1 risk. -- **Split**: safe subset can ship while risky scope waits. -- **Stage**: ship behind flag, cohort, or internal-only rollout. -- **Rollback/hotfix**: production behavior is already harmful. - -## Route Internally - -- `$pre-mortem` -- `$release-notes` -- `$post-launch-feedback-loop` -- `$metrics-review` -- `$verification` -- `$qa` -- `$dogfood` when a web UI needs browser-driven release evidence -- `$docs` -- `$comms-review` -- `$implementation-notes` - -## Required Output - -Return: - -1. **Release Scope**: changes, affected users, dependencies, and version/changelog needs. -2. **Readiness Evidence**: tests, QA result, known risks, rollback path, and monitoring. -3. **Review Readiness Dashboard**: gate status, evidence, required/missing/stale calls. -4. **Completion Audit**: planned items, implemented evidence, missing work, and drift. -5. **Rollout Plan**: deploy, monitor, rollback, support, and owner. -6. **Decision**: ship, conditional ship, hold, split, rollback, hotfix, or stage. -7. **Post-Release Loop**: owner, metric, feedback path, review time, and next operate/grow trigger. diff --git a/skills/release/agents/openai.yaml b/skills/release/agents/openai.yaml deleted file mode 100644 index 7854f799..00000000 --- a/skills/release/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Release" - short_description: "Release gate for ship readiness, deployment decision, changelog needs, rollback risk, versioning, launch..." - brand_color: "#4F46E5" - default_prompt: "Use $release with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/release/productize.json b/skills/release/productize.json deleted file mode 100644 index e8e5920d..00000000 --- a/skills/release/productize.json +++ /dev/null @@ -1,51 +0,0 @@ -{ - "title": "Release", - "category": "Delivery", - "lifecycle": "Launch & Learn", - "tags": [ - "release", - "reviewer", - "gate", - "entry-point", - "ship-readiness", - "deployment", - "rollback", - "changelog", - "launch-coordination", - "delivery", - "ship", - "readiness", - "decision" - ], - "use_when": "Use Release when a feature, fix, experiment, or product slice is moving toward production and needs a ship, hold, split, rollback, or staged-release decision with QA, docs, comms, and monitoring aligned.", - "do_not_use_when": "Do not use Release to write only user-facing release notes, perform QA, design a product flow, review architecture, or create stakeholder messaging from scratch; call those routed skills or gates first.", - "output_artifact": "Release readiness report with scope, evidence, gate status, release decision, and post-release loop", - "routing_signals": [ - "release", - "ship-gate", - "ship-readiness", - "deploy", - "deployment-decision", - "rollback", - "staged-release", - "launch-coordination", - "go-no-go", - "delivery", - "gate", - "ship", - "readiness", - "deployment" - ], - "framework_fit": "Release fits the final coordination gate before production, when product changes must be checked against evidence, QA status, docs, comms, rollback path, monitoring, and the post-release operating loop.", - "failure_modes": [ - "Ships based on implementation completion alone without QA status, rollback path, monitoring, documentation, comms, and known-risk review.", - "Collapses release into release notes and misses the go/no-go decision, staged rollout options, owner handoffs, and post-release learning loop.", - "Blocks indefinitely without separating must-fix release risks from follow-up docs, comms, product, design, engineering, or growth work." - ], - "examples": [ - { - "prompt": "Use $release to make the ship gate decision for this release candidate, including QA, docs, comms, rollback, and monitoring readiness.", - "expected_artifact": "Release readiness report with scope, evidence, gate status, release decision, and post-release loop" - } - ] -} diff --git a/skills/remote-miro-workshops-from-transcripts-and-specs/SKILL.md b/skills/remote-miro-workshops-from-transcripts-and-specs/SKILL.md deleted file mode 100644 index 2b888e2d..00000000 --- a/skills/remote-miro-workshops-from-transcripts-and-specs/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: remote-miro-workshops-from-transcripts-and-specs -description: >- - Remote Miro workshops from transcripts and specs. Use when the user needs a product workflow - for stakeholder management related to remote miro workshops from transcripts and specs. - Trigger terms: workshops, miro, facilitation, remote. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Remote Miro workshops from transcripts and specs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `remote-miro-workshops-from-transcripts-and-specs` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Remote Miro workshops from transcripts and specs delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Remote Miro workshops from transcripts and specs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{TRANSCRIPT}} -- {{TIME_LIMIT}} -- {{GOAL}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Remote Miro workshops from transcripts and specs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a focused remote Miro workshop plan from `{{TRANSCRIPT}}` to achieve `{{GOAL}}` within `{{TIME_LIMIT}}` minutes. -- Create a sequenced agenda of 3-6 activities with dependencies where each activity output feeds the next. -- Include a global timeline that sums exactly to `{{TIME_LIMIT}}` (including intro, any break time, and wrap-up). -- Start with transcript analysis (themes, decisions/questions, constraints/risks, assumptions). -- For each activity include objective, duration, format, participant instructions, facilitator notes with concrete Miro steps, materials/tools, and output artifact. -- Include bias-mitigation and accessibility practices, plus contingency handling for +/-10% time slip. -- End with wrap-up handoff (decision log, owners, deadlines, artifacts, comms plan) and an alternative action if full goal is not achieved. -- If the goal is unrealistic for the time limit, state why and propose a right-sized goal or revised duration. - -FORMAT -Return exactly this structure: - -### Transcript Analysis -- **Key themes:** [text] -- **Decisions/questions to answer:** [text] -- **Constraints & risks:** [text] -- **Assumptions (if any):** [text] - -### Global Timeline (sums to `{{TIME_LIMIT}}`) -- 00:00-00:XX [step] โ€” **XX min** -- [additional timed steps] -- [final step ending at `{{TIME_LIMIT}}`] โ€” **ZZ min** -- **Total: `{{TIME_LIMIT}}` minutes** - -### Pre-Read (send 24-48h before) -- [item] - -### Activities -#### Activity 1: *[Name]* -- **Objective:** [text] -- **Duration:** [x] minutes -- **Format:** [text] -- **Participant instructions:** [text] -- **Facilitator notes (with Miro steps):** - - Board: [frame/template/lock-unlock actions] - - Breakouts: [pod setup + return protocol] - - Timer: [minutes + buffer] - - Voting: [votes/person + criteria + rounds] - - Capture: [tags/colors/export method] -- **Materials & tools:** [text] -- **Output artifact:** [text] - -[Repeat for each activity, total 3-6] - -### Wrap-Up & Decision Handoff -- **Decision log:** [text] -- **Owners & deadlines:** [text] -- **Artifacts:** [text] -- **Communication plan:** [text] - -### Alternative Action (if goal not achieved) -- **Why not:** [text] -- **Fallback:** [right-sized option or Part 2 with exact minutes] -- **Prereqs for next session:** [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Timeline durations do not sum exactly to `{{TIME_LIMIT}}`. -- Agenda has fewer than 3 or more than 6 activities. -- Activities do not specify actionable Miro runbook steps or output dependencies. -- Missing bias/accessibility practices, contingencies, or alternative action path. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/remote-miro-workshops-from-transcripts-and-specs/SKILL.md.tmpl b/skills/remote-miro-workshops-from-transcripts-and-specs/SKILL.md.tmpl deleted file mode 100644 index c29a77de..00000000 --- a/skills/remote-miro-workshops-from-transcripts-and-specs/SKILL.md.tmpl +++ /dev/null @@ -1,104 +0,0 @@ ---- -name: remote-miro-workshops-from-transcripts-and-specs -description: >- - Remote Miro workshops from transcripts and specs. Use when the user needs a product workflow - for stakeholder management related to remote miro workshops from transcripts and specs. - Trigger terms: workshops, miro, facilitation, remote. ---- -# Remote Miro workshops from transcripts and specs - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Remote Miro workshops from transcripts and specs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{TRANSCRIPT}} -- {{TIME_LIMIT}} -- {{GOAL}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Remote Miro workshops from transcripts and specs. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a focused remote Miro workshop plan from `{{TRANSCRIPT}}` to achieve `{{GOAL}}` within `{{TIME_LIMIT}}` minutes. -- Create a sequenced agenda of 3-6 activities with dependencies where each activity output feeds the next. -- Include a global timeline that sums exactly to `{{TIME_LIMIT}}` (including intro, any break time, and wrap-up). -- Start with transcript analysis (themes, decisions/questions, constraints/risks, assumptions). -- For each activity include objective, duration, format, participant instructions, facilitator notes with concrete Miro steps, materials/tools, and output artifact. -- Include bias-mitigation and accessibility practices, plus contingency handling for +/-10% time slip. -- End with wrap-up handoff (decision log, owners, deadlines, artifacts, comms plan) and an alternative action if full goal is not achieved. -- If the goal is unrealistic for the time limit, state why and propose a right-sized goal or revised duration. - -FORMAT -Return exactly this structure: - -### Transcript Analysis -- **Key themes:** [text] -- **Decisions/questions to answer:** [text] -- **Constraints & risks:** [text] -- **Assumptions (if any):** [text] - -### Global Timeline (sums to `{{TIME_LIMIT}}`) -- 00:00-00:XX [step] โ€” **XX min** -- [additional timed steps] -- [final step ending at `{{TIME_LIMIT}}`] โ€” **ZZ min** -- **Total: `{{TIME_LIMIT}}` minutes** - -### Pre-Read (send 24-48h before) -- [item] - -### Activities -#### Activity 1: *[Name]* -- **Objective:** [text] -- **Duration:** [x] minutes -- **Format:** [text] -- **Participant instructions:** [text] -- **Facilitator notes (with Miro steps):** - - Board: [frame/template/lock-unlock actions] - - Breakouts: [pod setup + return protocol] - - Timer: [minutes + buffer] - - Voting: [votes/person + criteria + rounds] - - Capture: [tags/colors/export method] -- **Materials & tools:** [text] -- **Output artifact:** [text] - -[Repeat for each activity, total 3-6] - -### Wrap-Up & Decision Handoff -- **Decision log:** [text] -- **Owners & deadlines:** [text] -- **Artifacts:** [text] -- **Communication plan:** [text] - -### Alternative Action (if goal not achieved) -- **Why not:** [text] -- **Fallback:** [right-sized option or Part 2 with exact minutes] -- **Prereqs for next session:** [text] - -FAILURE -- Any required section is missing or materially incomplete. -- Timeline durations do not sum exactly to `{{TIME_LIMIT}}`. -- Agenda has fewer than 3 or more than 6 activities. -- Activities do not specify actionable Miro runbook steps or output dependencies. -- Missing bias/accessibility practices, contingencies, or alternative action path. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/remote-miro-workshops-from-transcripts-and-specs/agents/openai.yaml b/skills/remote-miro-workshops-from-transcripts-and-specs/agents/openai.yaml deleted file mode 100644 index fd63efbd..00000000 --- a/skills/remote-miro-workshops-from-transcripts-and-specs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Remote Miro workshops from transcripts and specs" - short_description: "Remote Miro workshops from transcripts and specs. Use when the user needs a product workflow for stakeholder..." - brand_color: "#7C3AED" - default_prompt: "Use $remote-miro-workshops-from-transcripts-and-specs with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/remote-miro-workshops-from-transcripts-and-specs/productize.json b/skills/remote-miro-workshops-from-transcripts-and-specs/productize.json deleted file mode 100644 index 1834dc99..00000000 --- a/skills/remote-miro-workshops-from-transcripts-and-specs/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Remote Miro workshops from transcripts and specs", - "category": "Operations", - "lifecycle": "Plan", - "tags": [ - "remote-miro-workshops-from-transcripts-and-specs", - "remote", - "miro", - "workshops", - "transcripts", - "specs" - ], - "use_when": "Remote Miro workshops from transcripts and specs. Use when the user needs a product workflow for stakeholder management related to remote miro workshops from transcripts and specs. Trigger terms: workshops, miro, facilitation, remote.", - "do_not_use_when": "Do not use Remote Miro workshops from transcripts and specs when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Remote Miro workshops from transcripts and specs delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "remote-miro-workshops-from-transcripts-and-specs", - "remote", - "miro", - "workshops", - "transcripts", - "specs" - ], - "framework_fit": "Remote Miro workshops from transcripts and specs fits Operations work in the Plan lifecycle when the user needs Remote Miro workshops from transcripts and specs delivery brief with scope, requirements, priorities, risks, and acceptance criteria and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Remote Miro workshops from transcripts and specs delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Remote Miro workshops from transcripts and specs as generic Operations advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Remote Miro workshops from transcripts and specs when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $remote-miro-workshops-from-transcripts-and-specs to turn this remote context into a decision-ready Remote Miro workshops from transcripts and specs delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Remote Miro workshops from transcripts and specs delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/requirements-prioritization-with-p0-p1-p2-framework/SKILL.md b/skills/requirements-prioritization-with-p0-p1-p2-framework/SKILL.md deleted file mode 100644 index 983124e5..00000000 --- a/skills/requirements-prioritization-with-p0-p1-p2-framework/SKILL.md +++ /dev/null @@ -1,333 +0,0 @@ ---- -name: requirements-prioritization-with-p0-p1-p2-framework -description: >- - Requirements prioritization with P0-P1-P2 framework. Use when the user needs a product - workflow for project management related to requirements prioritization with p0-p1-p2 - framework. Trigger terms: prioritization, product-management, planning, scope. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Requirements prioritization with P0-P1-P2 framework - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `requirements-prioritization-with-p0-p1-p2-framework` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Requirements prioritization with P0-P1-P2 framework delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Requirements prioritization with P0-P1-P2 framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{REQUIREMENTS_LIST}} -- {{PRODUCT_CONTEXT}} -- {{CONSTRAINTS}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Requirements prioritization with P0-P1-P2 framework. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Prioritize `{{REQUIREMENTS_LIST}}` using the P0/P1/P2 framework in the context of `{{PRODUCT_CONTEXT}}` and `{{CONSTRAINTS}}`. -- Apply explicit prioritization tests for each tier (P0/P1/P2) and challenge โ€œmust-haveโ€ claims. -- Use effort vs. value to support decisions and identify descoping options if capacity is exceeded. -- Provide rationale, evidence, and acceptance criteria for each requirement. -- Produce a capacity analysis and a stakeholder communication plan. - -FORMAT -Return exactly this structure: - -<requirements_prioritization> -<prioritization_framework> -**P0 Definition (Launch Blocker):** -[Your specific definition for this project: -- Without this, users cannot [core task] -- Without this, product fails [critical requirement] -- Must-have criteria: [specific tests]] - -**P1 Definition (High Value):** -[Your specific definition for this project: -- Significantly improves [key experience] -- Enables [important use case] -- Should-have criteria: [specific tests]] - -**P2 Definition (Nice-to-Have):** -[Your specific definition for this project: -- Enhances [aspect of experience] -- Valuable but users can accomplish goals without it -- Nice-to-have criteria: [specific tests]] - -**Prioritization Principles:** -[3-5 principles guiding decisions for this project: -- "Core user task enablement trumps convenience features" -- "Baseline quality must be met (P0) before adding polish (P2)"] -</prioritization_framework> - -<prioritized_requirements> -<p0_requirements> -[For each P0 requirement: - -**Requirement:** [Clear description] - -**Why P0:** -[Specific justification using P0 criteria] - -**Impact if Missing:** -[Concrete description of what breaks without this] - -**User Tasks Blocked:** -[Which core user tasks become impossible] - -**Evidence:** -[Data/research supporting this priority] - -**Effort Estimate:** -[Time/complexity] - -**Dependencies:** -[What else must exist for this to work] - -**Acceptance Criteria:** -[Minimum bar for "done" on this requirement]] -</p0_requirements> - -<p1_requirements> -[For each P1 requirement: - -**Requirement:** [Clear description] - -**Why P1:** -[Specific justification using P1 criteria] - -**Value if Included:** -[Concrete benefits of including this] - -**Impact if Missing:** -[What degrades without this, but doesn't break] - -**User Tasks Affected:** -[Which tasks become harder but still possible] - -**Evidence:** -[Data/research supporting value] - -**Effort Estimate:** -[Time/complexity] - -**Could Descope to:** -[Simpler version that captures core value] - -**Acceptance Criteria:** -[Minimum bar for "done"]] -</p1_requirements> - -<p2_requirements> -[For each P2 requirement: - -**Requirement:** [Clear description] - -**Why P2:** -[Why it's nice-to-have but not critical] - -**Value:** -[What it adds] - -**Defer Rationale:** -[Why it's okay to wait] - -**Effort Estimate:** -[Time/complexity] - -**Post-Launch Timeline:** -[When to revisit] - -**Acceptance Criteria:** -[If we did build it, what's the bar]] -</p2_requirements> -</prioritized_requirements> - -<challenged_priorities> -[For items originally claimed as "must-have" but deprioritized: - -**Requirement:** [Description] - -**Originally Claimed As:** [P0/P1] - -**Actually:** [P1/P2] - -**Why Deprioritized:** -[Reason it's not as critical as claimed] - -**Supporting Evidence:** -[Why this priority is more accurate] - -**Alternative:** -[How users can accomplish goal without this, or simpler version]] -</challenged_priorities> - -<effort_value_matrix> -[Create a 2x2 showing: -**High Value / Low Effort (Do First):** -- [List requirements] - -**High Value / High Effort (Evaluate):** -- [List requirements] -- [For each: Is value worth effort? Can we simplify?] - -**Low Value / Low Effort (Nice-to-have):** -- [List requirements] -- [Consider: Worth including or better to focus elsewhere?] - -**Low Value / High Effort (Descope):** -- [List requirements] -- [Rationale for cutting]] -</effort_value_matrix> - -<capacity_analysis> -**Total Requirements:** -- P0: [count] items = [estimated effort] -- P1: [count] items = [estimated effort] -- P2: [count] items = [estimated effort] -- Total: [total effort] - -**Available Capacity:** -[Team capacity for this release] - -**Gap Analysis:** -- P0 fit: [Yes/No - if no, how much over?] -- P0 + P1 fit: [Yes/No - if no, which P1 to defer?] -- P0 + P1 + P2 fit: [Almost certainly no] - -**Conclusion:** -[What's realistic to complete] -</capacity_analysis> - -<descoping_options> -[If capacity is exceeded, propose descoping approaches: - -**Option 1: Defer All P2** -- What's cut: [List P2 items] -- What's preserved: [All P0/P1] -- Impact: [Minimal - nice-to-haves wait] - -**Option 2: Defer Low-Effort P1 + All P2** -- What's cut: [Specific P1 items] -- What's preserved: [High-value P0/P1] -- Rationale: [Why these P1 items can wait] -- Impact: [Description] - -**Option 3: Simplify High-Effort P1** -- What's simplified: [Specific items] -- Simplified version: [Description] -- Value preserved: [What's kept] -- Impact: [Tradeoffs] - -**Recommended Approach:** -[Which option, with rationale]] -</descoping_options> - -<decision_documentation> -**Prioritization Decision Log:** -[Template for documenting: -- Requirement -- Priority assignment (P0/P1/P2) -- Rationale -- Decision maker -- Date -- Conditions that would change priority] -</decision_documentation> - -<communication_plan> -**How to Present Prioritization:** -[Guidance for sharing with stakeholders: -- Lead with framework and principles -- Show evidence for priorities -- Be explicit about tradeoffs -- Invite challenge on specific items -- Document decisions] - -**Handling "Everything is P0" Stakeholders:** -[Tactics for managing pushback: -- Apply prioritization tests consistently -- Show capacity constraints -- Offer descoping choices -- Escalate if needed] -</communication_plan> -</requirements_prioritization> - -FAILURE -- Any required section in `<requirements_prioritization>` is missing or materially incomplete. -- Requirements lack evidence-based rationale or acceptance criteria. -- Capacity analysis or descoping options are missing when P0+P1 exceed capacity. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/requirements-prioritization-with-p0-p1-p2-framework/SKILL.md.tmpl b/skills/requirements-prioritization-with-p0-p1-p2-framework/SKILL.md.tmpl deleted file mode 100644 index 1023e342..00000000 --- a/skills/requirements-prioritization-with-p0-p1-p2-framework/SKILL.md.tmpl +++ /dev/null @@ -1,274 +0,0 @@ ---- -name: requirements-prioritization-with-p0-p1-p2-framework -description: >- - Requirements prioritization with P0-P1-P2 framework. Use when the user needs a product - workflow for project management related to requirements prioritization with p0-p1-p2 - framework. Trigger terms: prioritization, product-management, planning, scope. ---- -# Requirements prioritization with P0-P1-P2 framework - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Requirements prioritization with P0-P1-P2 framework**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{REQUIREMENTS_LIST}} -- {{PRODUCT_CONTEXT}} -- {{CONSTRAINTS}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Requirements prioritization with P0-P1-P2 framework. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Prioritize `{{REQUIREMENTS_LIST}}` using the P0/P1/P2 framework in the context of `{{PRODUCT_CONTEXT}}` and `{{CONSTRAINTS}}`. -- Apply explicit prioritization tests for each tier (P0/P1/P2) and challenge โ€œmust-haveโ€ claims. -- Use effort vs. value to support decisions and identify descoping options if capacity is exceeded. -- Provide rationale, evidence, and acceptance criteria for each requirement. -- Produce a capacity analysis and a stakeholder communication plan. - -FORMAT -Return exactly this structure: - -<requirements_prioritization> -<prioritization_framework> -**P0 Definition (Launch Blocker):** -[Your specific definition for this project: -- Without this, users cannot [core task] -- Without this, product fails [critical requirement] -- Must-have criteria: [specific tests]] - -**P1 Definition (High Value):** -[Your specific definition for this project: -- Significantly improves [key experience] -- Enables [important use case] -- Should-have criteria: [specific tests]] - -**P2 Definition (Nice-to-Have):** -[Your specific definition for this project: -- Enhances [aspect of experience] -- Valuable but users can accomplish goals without it -- Nice-to-have criteria: [specific tests]] - -**Prioritization Principles:** -[3-5 principles guiding decisions for this project: -- "Core user task enablement trumps convenience features" -- "Baseline quality must be met (P0) before adding polish (P2)"] -</prioritization_framework> - -<prioritized_requirements> -<p0_requirements> -[For each P0 requirement: - -**Requirement:** [Clear description] - -**Why P0:** -[Specific justification using P0 criteria] - -**Impact if Missing:** -[Concrete description of what breaks without this] - -**User Tasks Blocked:** -[Which core user tasks become impossible] - -**Evidence:** -[Data/research supporting this priority] - -**Effort Estimate:** -[Time/complexity] - -**Dependencies:** -[What else must exist for this to work] - -**Acceptance Criteria:** -[Minimum bar for "done" on this requirement]] -</p0_requirements> - -<p1_requirements> -[For each P1 requirement: - -**Requirement:** [Clear description] - -**Why P1:** -[Specific justification using P1 criteria] - -**Value if Included:** -[Concrete benefits of including this] - -**Impact if Missing:** -[What degrades without this, but doesn't break] - -**User Tasks Affected:** -[Which tasks become harder but still possible] - -**Evidence:** -[Data/research supporting value] - -**Effort Estimate:** -[Time/complexity] - -**Could Descope to:** -[Simpler version that captures core value] - -**Acceptance Criteria:** -[Minimum bar for "done"]] -</p1_requirements> - -<p2_requirements> -[For each P2 requirement: - -**Requirement:** [Clear description] - -**Why P2:** -[Why it's nice-to-have but not critical] - -**Value:** -[What it adds] - -**Defer Rationale:** -[Why it's okay to wait] - -**Effort Estimate:** -[Time/complexity] - -**Post-Launch Timeline:** -[When to revisit] - -**Acceptance Criteria:** -[If we did build it, what's the bar]] -</p2_requirements> -</prioritized_requirements> - -<challenged_priorities> -[For items originally claimed as "must-have" but deprioritized: - -**Requirement:** [Description] - -**Originally Claimed As:** [P0/P1] - -**Actually:** [P1/P2] - -**Why Deprioritized:** -[Reason it's not as critical as claimed] - -**Supporting Evidence:** -[Why this priority is more accurate] - -**Alternative:** -[How users can accomplish goal without this, or simpler version]] -</challenged_priorities> - -<effort_value_matrix> -[Create a 2x2 showing: -**High Value / Low Effort (Do First):** -- [List requirements] - -**High Value / High Effort (Evaluate):** -- [List requirements] -- [For each: Is value worth effort? Can we simplify?] - -**Low Value / Low Effort (Nice-to-have):** -- [List requirements] -- [Consider: Worth including or better to focus elsewhere?] - -**Low Value / High Effort (Descope):** -- [List requirements] -- [Rationale for cutting]] -</effort_value_matrix> - -<capacity_analysis> -**Total Requirements:** -- P0: [count] items = [estimated effort] -- P1: [count] items = [estimated effort] -- P2: [count] items = [estimated effort] -- Total: [total effort] - -**Available Capacity:** -[Team capacity for this release] - -**Gap Analysis:** -- P0 fit: [Yes/No - if no, how much over?] -- P0 + P1 fit: [Yes/No - if no, which P1 to defer?] -- P0 + P1 + P2 fit: [Almost certainly no] - -**Conclusion:** -[What's realistic to complete] -</capacity_analysis> - -<descoping_options> -[If capacity is exceeded, propose descoping approaches: - -**Option 1: Defer All P2** -- What's cut: [List P2 items] -- What's preserved: [All P0/P1] -- Impact: [Minimal - nice-to-haves wait] - -**Option 2: Defer Low-Effort P1 + All P2** -- What's cut: [Specific P1 items] -- What's preserved: [High-value P0/P1] -- Rationale: [Why these P1 items can wait] -- Impact: [Description] - -**Option 3: Simplify High-Effort P1** -- What's simplified: [Specific items] -- Simplified version: [Description] -- Value preserved: [What's kept] -- Impact: [Tradeoffs] - -**Recommended Approach:** -[Which option, with rationale]] -</descoping_options> - -<decision_documentation> -**Prioritization Decision Log:** -[Template for documenting: -- Requirement -- Priority assignment (P0/P1/P2) -- Rationale -- Decision maker -- Date -- Conditions that would change priority] -</decision_documentation> - -<communication_plan> -**How to Present Prioritization:** -[Guidance for sharing with stakeholders: -- Lead with framework and principles -- Show evidence for priorities -- Be explicit about tradeoffs -- Invite challenge on specific items -- Document decisions] - -**Handling "Everything is P0" Stakeholders:** -[Tactics for managing pushback: -- Apply prioritization tests consistently -- Show capacity constraints -- Offer descoping choices -- Escalate if needed] -</communication_plan> -</requirements_prioritization> - -FAILURE -- Any required section in `<requirements_prioritization>` is missing or materially incomplete. -- Requirements lack evidence-based rationale or acceptance criteria. -- Capacity analysis or descoping options are missing when P0+P1 exceed capacity. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/requirements-prioritization-with-p0-p1-p2-framework/agents/openai.yaml b/skills/requirements-prioritization-with-p0-p1-p2-framework/agents/openai.yaml deleted file mode 100644 index c18efe6a..00000000 --- a/skills/requirements-prioritization-with-p0-p1-p2-framework/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Requirements prioritization with P0-P1-P2 framework" - short_description: "Requirements prioritization with P0-P1-P2 framework. Use when the user needs a product workflow for project..." - brand_color: "#4F46E5" - default_prompt: "Use $requirements-prioritization-with-p0-p1-p2-framework with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/requirements-prioritization-with-p0-p1-p2-framework/productize.json b/skills/requirements-prioritization-with-p0-p1-p2-framework/productize.json deleted file mode 100644 index 4aae98e7..00000000 --- a/skills/requirements-prioritization-with-p0-p1-p2-framework/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Requirements prioritization with P0-P1-P2 framework", - "category": "Delivery", - "lifecycle": "Plan", - "tags": [ - "requirements-prioritization-with-p0-p1-p2-framework", - "requirements", - "prioritization", - "framework", - "project", - "management", - "delivery" - ], - "use_when": "Requirements prioritization with P0-P1-P2 framework. Use when the user needs a product workflow for project management related to requirements prioritization with p0-p1-p2 framework. Trigger terms: prioritization, product-management, planning, scope.", - "do_not_use_when": "Do not use Requirements prioritization with P0-P1-P2 framework when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Requirements prioritization with P0-P1-P2 framework delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "requirements-prioritization-with-p0-p1-p2-framework", - "requirements", - "prioritization", - "framework", - "project", - "management", - "delivery" - ], - "framework_fit": "Appropriate when competing requirements, stakeholder requests, or roadmap candidates need explicit priority levels and delivery tradeoffs.", - "failure_modes": [ - "Produces Requirements prioritization with P0-P1-P2 framework delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Requirements prioritization with P0-P1-P2 framework as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Requirements prioritization with P0-P1-P2 framework when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $requirements-prioritization-with-p0-p1-p2-framework to turn this requirements context into a decision-ready Requirements prioritization with P0-P1-P2 framework delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Requirements prioritization with P0-P1-P2 framework delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/research-into-durable-competitive-moats/SKILL.md b/skills/research-into-durable-competitive-moats/SKILL.md deleted file mode 100644 index e4965cac..00000000 --- a/skills/research-into-durable-competitive-moats/SKILL.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -name: research-into-durable-competitive-moats -description: >- - Research into durable competitive moats. Use when the user needs a product workflow for - product strategy related to research into durable competitive moats. Trigger terms: moats, - product-strategy, competitive-advantage, research-synthesis. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Research into durable competitive moats - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `research-into-durable-competitive-moats` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Research into durable competitive moats research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Research into durable competitive moats**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{APP_CONTEXT}} -- {{RESEARCH_BUNDLE}} -- Optional: {{K_STRATEGIES}} # default 10 -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Research into durable competitive moats. -Success metric: -- Produces research-grounded moat insights and converts them into implementation-ready strategies. -- Delivers a diversified moat portfolio with explicit probabilities, defensibility, and kill criteria. -- Keeps recommendations constrained by feasibility, compounding potential, and non-copyability. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{APP_CONTEXT}}` and `{{RESEARCH_BUNDLE}}`; if critical info is missing, add explicit assumptions in a top-level `assumptions` array. -- Extract 8-15 research-backed insights; each insight must include: - - `id` (e.g., `I1`), - - `insight` (one sentence), - - `evidence` (quote/paraphrase + source cue), - - `implication` (competitive implication). -- Generate `k` moat strategies (`k={{K_STRATEGIES}}` if provided; otherwise 10). -- Allowed `moat_type` values: - - `data moat`, `network effects`, `switching costs`, `distribution moat`, `brand`, `scale economies`, `ecosystem/platform`, `regulatory/permissions`, `IP/know-how`, `community`. -- Each strategy must include: - - `title`, - - `moat_type`, - - `contrarian` (boolean), - - `mechanism`, - - `research_link` (insight IDs), - - `implementation_plan` (`now_30d`, `next_90d`, `next_12m`, each 3-6 steps), - - `prerequisites`, - - `metrics` (3-6 leading indicators with targets), - - `risks_and_mitigations` (3-6), - - `time_to_moat` (`<3 months`, `3-6 months`, `6-12 months`, `12-24 months`, `24+ months`), - - `estimated_cost` (`low`, `medium`, `high`), - - `defensibility_score` (1-10) and `defensibility_justification`, - - `probability` (decimal 0.0-1.0). -- Diversity constraints: - - every strategy probability `< 0.15`, - - at least 3 strategies with probability `< 0.07`, - - no `moat_type` used more than twice, - - at least 2 strategies with `contrarian=true`. -- Portfolio section must include: - - `recommended_portfolio` (exactly 3 strategies with rationale), - - `kill_criteria` (2-3 falsifiable stop criteria per recommended strategy), - - `sequencing` (month-by-month plan for 6 months with dependencies). -- Output must be valid JSON only, concise and implementation-ready. - -FORMAT -Return exactly this structure: - -{ - "assumptions": ["[Only if needed]"], - "insights": [ - { - "id": "I1", - "insight": "", - "evidence": "", - "implication": "" - } - ], - "moat_strategies": [ - { - "title": "", - "moat_type": "", - "contrarian": false, - "mechanism": "", - "research_link": ["I1"], - "implementation_plan": { - "now_30d": ["", "", ""], - "next_90d": ["", "", ""], - "next_12m": ["", "", ""] - }, - "prerequisites": [""], - "metrics": [ - { - "name": "", - "target": "" - } - ], - "risks_and_mitigations": [ - { - "risk": "", - "mitigation": "" - } - ], - "time_to_moat": "", - "estimated_cost": "", - "defensibility_score": 1, - "defensibility_justification": "", - "probability": 0.01 - } - ], - "recommended_portfolio": [ - { - "strategy_title": "", - "rationale": "" - } - ], - "kill_criteria": [ - { - "strategy_title": "", - "criteria": ["", ""] - } - ], - "sequencing": [ - { - "month": "M1", - "focus": "", - "dependencies": [""] - } - ] -} - -FAILURE -- Output is not valid JSON. -- Required top-level keys are missing or malformed. -- Insight count is outside 8-15. -- Strategy count does not equal `k` (default 10). -- Any strategy misses required fields or contains invalid enum values. -- Distribution constraints are violated (probability caps, low-probability count, moat-type repetition, contrarian minimum). -- `recommended_portfolio` does not contain exactly 3 strategies. -- Kill criteria are not falsifiable or have fewer than 2 criteria per recommended strategy. -- Sequencing is not month-by-month for 6 months. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/research-into-durable-competitive-moats/SKILL.md.tmpl b/skills/research-into-durable-competitive-moats/SKILL.md.tmpl deleted file mode 100644 index af6d7bf2..00000000 --- a/skills/research-into-durable-competitive-moats/SKILL.md.tmpl +++ /dev/null @@ -1,151 +0,0 @@ ---- -name: research-into-durable-competitive-moats -description: >- - Research into durable competitive moats. Use when the user needs a product workflow for - product strategy related to research into durable competitive moats. Trigger terms: moats, - product-strategy, competitive-advantage, research-synthesis. ---- -# Research into durable competitive moats - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Research into durable competitive moats**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{APP_CONTEXT}} -- {{RESEARCH_BUNDLE}} -- Optional: {{K_STRATEGIES}} # default 10 -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Research into durable competitive moats. -Success metric: -- Produces research-grounded moat insights and converts them into implementation-ready strategies. -- Delivers a diversified moat portfolio with explicit probabilities, defensibility, and kill criteria. -- Keeps recommendations constrained by feasibility, compounding potential, and non-copyability. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{APP_CONTEXT}}` and `{{RESEARCH_BUNDLE}}`; if critical info is missing, add explicit assumptions in a top-level `assumptions` array. -- Extract 8-15 research-backed insights; each insight must include: - - `id` (e.g., `I1`), - - `insight` (one sentence), - - `evidence` (quote/paraphrase + source cue), - - `implication` (competitive implication). -- Generate `k` moat strategies (`k={{K_STRATEGIES}}` if provided; otherwise 10). -- Allowed `moat_type` values: - - `data moat`, `network effects`, `switching costs`, `distribution moat`, `brand`, `scale economies`, `ecosystem/platform`, `regulatory/permissions`, `IP/know-how`, `community`. -- Each strategy must include: - - `title`, - - `moat_type`, - - `contrarian` (boolean), - - `mechanism`, - - `research_link` (insight IDs), - - `implementation_plan` (`now_30d`, `next_90d`, `next_12m`, each 3-6 steps), - - `prerequisites`, - - `metrics` (3-6 leading indicators with targets), - - `risks_and_mitigations` (3-6), - - `time_to_moat` (`<3 months`, `3-6 months`, `6-12 months`, `12-24 months`, `24+ months`), - - `estimated_cost` (`low`, `medium`, `high`), - - `defensibility_score` (1-10) and `defensibility_justification`, - - `probability` (decimal 0.0-1.0). -- Diversity constraints: - - every strategy probability `< 0.15`, - - at least 3 strategies with probability `< 0.07`, - - no `moat_type` used more than twice, - - at least 2 strategies with `contrarian=true`. -- Portfolio section must include: - - `recommended_portfolio` (exactly 3 strategies with rationale), - - `kill_criteria` (2-3 falsifiable stop criteria per recommended strategy), - - `sequencing` (month-by-month plan for 6 months with dependencies). -- Output must be valid JSON only, concise and implementation-ready. - -FORMAT -Return exactly this structure: - -{ - "assumptions": ["[Only if needed]"], - "insights": [ - { - "id": "I1", - "insight": "", - "evidence": "", - "implication": "" - } - ], - "moat_strategies": [ - { - "title": "", - "moat_type": "", - "contrarian": false, - "mechanism": "", - "research_link": ["I1"], - "implementation_plan": { - "now_30d": ["", "", ""], - "next_90d": ["", "", ""], - "next_12m": ["", "", ""] - }, - "prerequisites": [""], - "metrics": [ - { - "name": "", - "target": "" - } - ], - "risks_and_mitigations": [ - { - "risk": "", - "mitigation": "" - } - ], - "time_to_moat": "", - "estimated_cost": "", - "defensibility_score": 1, - "defensibility_justification": "", - "probability": 0.01 - } - ], - "recommended_portfolio": [ - { - "strategy_title": "", - "rationale": "" - } - ], - "kill_criteria": [ - { - "strategy_title": "", - "criteria": ["", ""] - } - ], - "sequencing": [ - { - "month": "M1", - "focus": "", - "dependencies": [""] - } - ] -} - -FAILURE -- Output is not valid JSON. -- Required top-level keys are missing or malformed. -- Insight count is outside 8-15. -- Strategy count does not equal `k` (default 10). -- Any strategy misses required fields or contains invalid enum values. -- Distribution constraints are violated (probability caps, low-probability count, moat-type repetition, contrarian minimum). -- `recommended_portfolio` does not contain exactly 3 strategies. -- Kill criteria are not falsifiable or have fewer than 2 criteria per recommended strategy. -- Sequencing is not month-by-month for 6 months. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/research-into-durable-competitive-moats/agents/openai.yaml b/skills/research-into-durable-competitive-moats/agents/openai.yaml deleted file mode 100644 index f4331ef5..00000000 --- a/skills/research-into-durable-competitive-moats/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Research into durable competitive moats" - short_description: "Research into durable competitive moats. Use when the user needs a product workflow for product strategy related to..." - brand_color: "#0D9488" - default_prompt: "Use $research-into-durable-competitive-moats with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/research-into-durable-competitive-moats/productize.json b/skills/research-into-durable-competitive-moats/productize.json deleted file mode 100644 index bd1a22a2..00000000 --- a/skills/research-into-durable-competitive-moats/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Research into durable competitive moats", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "research-into-durable-competitive-moats", - "research", - "durable", - "competitive", - "moats", - "discovery" - ], - "use_when": "Research into durable competitive moats. Use when the user needs a product workflow for product strategy related to research into durable competitive moats. Trigger terms: moats, product-strategy, competitive-advantage, research-synthesis.", - "do_not_use_when": "Do not use Research into durable competitive moats when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Research into durable competitive moats research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "research-into-durable-competitive-moats", - "research", - "durable", - "competitive", - "moats", - "discovery" - ], - "framework_fit": "Research into durable competitive moats fits Discovery work in the Discover lifecycle when the user needs Research into durable competitive moats research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Research into durable competitive moats research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Research into durable competitive moats as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Research into durable competitive moats when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $research-into-durable-competitive-moats to turn this research context into a decision-ready Research into durable competitive moats research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Research into durable competitive moats research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/review-round/SKILL.md b/skills/review-round/SKILL.md new file mode 100644 index 00000000..a4fd17ec --- /dev/null +++ b/skills/review-round/SKILL.md @@ -0,0 +1,120 @@ +--- +name: review-round +description: Performs a comprehensive code review of a PRD implementation and generates a review round directory with issue files compatible with fix-reviews. Use when reviewing implemented PRD tasks, creating a manual review round without an external provider, or performing a quality audit of code changes. Do not use for fetching reviews from external providers, fixing existing review issues, executing PRD tasks, or editing source code. +--- + +# Review Round + +Perform a structured code review of a PRD implementation and produce a review round directory that the `fix-reviews` workflow can process. + +## Required Inputs + +- Feature name identifying the `.productize/tasks/<name>/` directory. +- Optional: specific files or directories to scope the review. + +## Workflow + +1. Determine the review round directory. + - Derive the PRD directory from the feature name: `.productize/tasks/<name>/`. + - Verify the PRD directory exists. If it does not, stop and report the missing directory. + - List existing `reviews-NNN/` subdirectories to determine the next round number. If none exist, use round 1. + - If prior review rounds exist, read their issue files to build a list of already-known issues. The current round must only contain NEW issues not already tracked in prior rounds. Do not re-flag issues that are pending, valid, or resolved in earlier rounds. + - Determine the review round directory path: `.productize/tasks/<name>/reviews-NNN/` with the round number zero-padded to 3 digits. Do NOT create it yet โ€” wait until step 4 confirms there are issues to write. This avoids leaving empty directories when the review finds no issues. + +2. Identify the review scope. + - Read `_prd.md`, `_techspec.md`, and `_tasks.md` from the PRD directory to understand what was implemented and why. + - Read ADRs from `.productize/tasks/<name>/adrs/` for architectural decision context. + - If `_prd.md` and `_techspec.md` are both missing, warn that the review will lack requirements context but proceed with a code-quality-only review. + - If the user provided specific files or directories, scope the review to those paths. + - If no explicit scope was provided, run `git diff main...HEAD --name-only` to discover all files created or modified on the current branch. If the diff is empty or unhelpful, ask the user to specify files. + - Spawn an Agent tool call to explore the identified files, their imports, and their dependencies to build a map of the implementation. + +3. Perform the code review. + - Read `references/review-criteria.md` for severity definitions and evaluation areas. + - **Prioritize the review scope.** If the scope contains more than 15 files, triage before deep-reading: identify the core implementation files (new packages, new exported APIs, files with the most additions) and review those in full first. Review remaining files (tests, minor edits, config changes) for obvious issues only. This prevents shallow reviews spread across too many files. + - Read every file in the prioritized scope completely before forming conclusions. + - **Requirements validation**: If `_prd.md` or `_techspec.md` were available in step 2, cross-check the implementation against every stated requirement, acceptance criterion, and architectural decision. Flag any requirement that is missing, partially implemented, or implemented differently than specified. These are correctness issues โ€” assign severity based on the gap's impact (critical if a core feature is missing, high if behavior deviates from spec, medium if an edge case from the spec is unhandled). + - Evaluate each file against the nine evaluation areas: Security, Correctness, Concurrency, Performance and Scalability, Error Handling, Code Quality and Maintainability, Testing, Architecture, and Operations. + - Identify issues in severity order: critical first, then high, medium, and low. + - For each issue record: the file path relative to the repository root, the approximate line number, the severity level, a concise title (max 72 characters), and a detailed review comment describing the problem and a suggested fix. + - **Deduplicate before writing.** If the same pattern (e.g., missing nil check, missing error wrap) appears in multiple files, create one issue for the most representative instance and list the other affected files in its Review Comment. Do not create N identical issues for N files exhibiting the same root cause. One issue per distinct problem, not per occurrence. + - **Verify before flagging.** Before creating an issue, check whether the pattern is intentional: look for adjacent comments explaining the choice, ADR references, or test coverage that validates the behavior. If code looks suspicious but has a clear justification (e.g., `// nolint: intentionally ignoring close error on read-only file`), do not create an issue. Only flag patterns that are genuinely problematic, not merely unconventional. + - Skip issues that linters or formatters already catch. Run `make lint` first to filter these out. + - **Focus on signal, not volume.** Aim for fewer, higher-quality issues rather than an exhaustive list. If you find more than 20 issues, re-evaluate: keep all critical and high issues, but prune medium and low issues to only the most impactful. A review with 8 precise issues is more useful than one with 30 that includes marginal concerns. + - Also note well-implemented aspects of the code. These observations inform the summary but do not produce issue files. + - If no issues are found after a thorough review, report that the implementation looks clean and skip steps 4 through 6. Do not create the review round directory. + +4. Generate issue files. + - Create the review round directory determined in step 1. + - Read `references/issue-template.md` for the canonical format. + - For each issue identified in step 3, create an `issue_NNN.md` file in the review round directory. + - Issue numbering starts at `001` and increments sequentially. + - Each file must use this exact structure: + + ``` + --- + provider: manual + pr: + round: <N> + round_created_at: <UTC timestamp in RFC3339 format> + status: pending + file: path/to/file.go + line: 42 + severity: high + author: claude-code + provider_ref: + --- + + # Issue NNN: <title> + + ## Review Comment + + <detailed review body> + + ## Triage + + - Decision: `UNREVIEWED` + - Notes: + ``` + + - The `<author>` field must be `claude-code`. + - The `provider_ref` field must be empty. + - The `provider` field must be `manual`. + - The `pr` field is empty for manual reviews. If the user provides a PR number, include it. + - The `round` field must match the directory number as an integer (not zero-padded). + - The `round_created_at` field must use the same current UTC RFC3339 timestamp in every issue in this round. + - The `severity` field must be exactly one of: `critical`, `high`, `medium`, `low`. + +5. Summarize and present the review. + - Print a summary listing: + - **Merge recommendation**: If any critical or high issues exist, state "Needs fixes before merge" with the blocking issues. If only medium/low issues exist, state "Safe to merge with follow-ups." If no issues, state "Clean โ€” ready to merge." + - Total issues found, broken down by severity (critical, high, medium, low). + - The review round directory path. + - The full list of generated issue file names. + - Well-implemented aspects observed during the review. + - Suggest running `productize reviews fix <name>` to process the review round. + +6. Verify before completion. + - Use installed `final-verify` before claiming the review round is complete. + - Read back each generated issue file and verify the frontmatter parses correctly. + - Verify every issue file in the round has matching `provider`, `pr`, `round`, and `round_created_at` values. + - Confirm the review round directory follows the `reviews-NNN` naming convention. + +## Critical Rules + +- Do not fix the issues found. This skill only identifies and documents issues. The `fix-reviews` workflow handles remediation. +- Do not create issue files for problems that linters or formatters already catch. +- Every issue file must have valid YAML frontmatter parseable by `prompt.ParseReviewContext()`. +- Do not create or maintain review `_meta.md`; round metadata lives in each issue file frontmatter. +- Do not create empty review rounds. If no issues are found, report a clean review and do not create the round directory. +- Do not modify any source code files. This is a review-only skill. +- Do not call provider-specific scripts or `gh` mutations. + +## Error Handling + +- If the PRD directory does not exist, stop and report the missing directory. +- If no files can be identified for review and the user did not provide explicit paths, ask the user to specify files. +- If both `_prd.md` and `_techspec.md` are missing, warn about the lack of requirements context but proceed with code-quality-only review. +- If the review round directory cannot be created, stop and report the filesystem error. +- If writing an issue file fails, stop and report which file could not be written. +- If `make lint` fails to run (build errors, missing tools), note the failure in the summary and proceed with the review. Do not skip the review because linting failed โ€” just acknowledge that linter-overlap filtering could not be applied. diff --git a/skills/review-round/references/issue-template.md b/skills/review-round/references/issue-template.md new file mode 100644 index 00000000..26b33d4b --- /dev/null +++ b/skills/review-round/references/issue-template.md @@ -0,0 +1,60 @@ +# Issue File Template + +Use this exact structure for every issue file. The file is parsed by +`reviews.ReadReviewEntries()` and `prompt.ParseReviewContext()`. + +## Format + +``` +--- +status: pending +file: path/to/file.go +line: 42 +severity: critical|high|medium|low +author: claude-code +provider_ref: +--- + +# Issue NNN: <concise title summarizing the problem> + +## Review Comment + +<detailed description of the issue, why it is a problem, +and a suggested fix with a concise code snippet if helpful> + +## Triage + +- Decision: `UNREVIEWED` +- Notes: +``` + +## Field Definitions + +- **NNN**: Three-digit zero-padded issue number (001, 002, ...). +- **status**: Starts as `pending`, then moves through `valid` or `invalid`, and ends as `resolved`. +- **title**: One-line summary of the problem. Maximum 72 characters. +- **file**: Relative path from repository root to the affected source file. + Use `unknown` only when the issue is purely architectural and not tied to a + specific file. +- **line**: Line number where the issue is most visible. Use `0` when no + specific line applies. +- **severity**: Exactly one of `critical`, `high`, `medium`, `low`. + Read `review-criteria.md` for definitions. +- **author**: Always `claude-code` for manual review rounds. +- **provider_ref**: Always empty for manual review rounds. + +## Parser Compatibility + +- The YAML frontmatter must be valid and parseable by `prompt.ParseReviewContext()`. +- Issue file names must match the pattern `issue_NNN.md` where NNN is a + zero-padded number, for `prompt.ExtractIssueNumber()` to recognize them. + +## Rules + +- One issue per file. Do not combine multiple unrelated problems. +- The Review Comment must be actionable: state the problem clearly and + provide a concrete suggestion for how to fix it. +- Keep code snippets in Review Comment under 15 lines. +- Keep the title descriptive but short. + Good: "Missing nil check before map access in resolveConfig". + Bad: "Code issue". diff --git a/skills/review-round/references/review-criteria.md b/skills/review-round/references/review-criteria.md new file mode 100644 index 00000000..2e3383c2 --- /dev/null +++ b/skills/review-round/references/review-criteria.md @@ -0,0 +1,123 @@ +# Review Criteria + +## Severity Levels + +### critical + +Security flaws, crashes, data loss, undefined behavior, or race conditions. +Issues that could cause production incidents or compromise user data. + +Examples: authentication bypass, SQL/command injection, nil pointer dereference +on a hot path, unbounded goroutine leak, writing sensitive data to logs. + +### high + +Bugs affecting correctness, performance bottlenecks visible to users, or +anti-patterns that significantly impair scalability, reliability, or usability. +These need fixing before merge. + +Examples: logic error returning wrong results, O(n^2) loop over unbounded +input, missing transaction rollback, error silently swallowed in a critical +path, missing input validation at a system boundary. + +### medium + +Maintainability concerns, code smells, test coverage gaps, or non-idiomatic +patterns that degrade long-term health. Not blocking but should be addressed. + +Examples: duplicated logic across packages, function exceeding 80 lines with +deep nesting, missing test for an error branch, context.Background() used +outside main, interface accepted but only one implementation exists. + +### low + +Minor improvements, documentation gaps, or naming suggestions. Optional +enhancements that improve clarity. + +Examples: unclear variable name, missing godoc on an exported function, +redundant type conversion, slightly misleading comment. + +## Evaluation Areas + +### 1. Security + +- Authentication and authorization flaws. +- Input validation gaps (injection, path traversal, XSS). +- Hardcoded secrets, tokens, or credentials. +- Cryptography misuse or insecure storage. +- Sensitive data exposure in logs or error messages. + +### 2. Correctness + +- Logic errors producing wrong results. +- Off-by-one and boundary condition bugs. +- Nil or null pointer dereferences. +- Unhandled error paths leading to silent failures. +- Incorrect type assertions or conversions. + +### 3. Concurrency + +- Race conditions and missing synchronization. +- Goroutine leaks (no shutdown path or context cancellation). +- Deadlock potential from lock ordering. +- Channel misuse (send on closed, unbuffered blocking). +- Missing `sync.WaitGroup` tracking for spawned goroutines. + +### 4. Performance and Scalability + +- Algorithmic complexity issues (O(n^2) where O(n) suffices). +- Resource leaks (file handles, HTTP bodies, database connections). +- Unbounded growth in slices, maps, or channels. +- Missing caching for repeated expensive operations. +- Blocking I/O on critical paths without timeout. + +### 5. Error Handling + +- Swallowed errors (assigned to `_` without justification). +- Missing error context (`fmt.Errorf("context: %w", err)`). +- `panic()` or `log.Fatal()` in library or handler code. +- Broad catch-all error handling masking specific failures. +- Incorrect use of `errors.Is()` or `errors.As()`. + +### 6. Code Quality and Maintainability + +- Readability issues (unclear naming, deeply nested logic). +- Code duplication across functions or packages. +- Overly complex functions that should be decomposed. +- Dead code or unused exports. +- Violations of project coding conventions. + +### 7. Testing + +- Missing tests for critical code paths. +- Tests that verify mocks instead of behavior. +- Flaky test patterns (time-dependent, order-dependent). +- Inadequate edge case and error path coverage. +- Missing `t.Parallel()` for independent subtests. + +### 8. Architecture + +- Circular dependencies between packages. +- Layer violations (e.g., CLI package importing internal runtime details). +- Leaky abstractions exposing implementation details. +- Tight coupling that prevents independent testing. +- Inconsistent patterns within the same codebase area. + +### 9. Operations + +- Missing or insufficient structured logging (`slog`). +- Missing error context for production debugging. +- Configuration values hardcoded instead of parameterized. +- Missing graceful shutdown handling for long-running processes. +- Observability gaps (no metrics or tracing on critical operations). + +## Review Approach + +- Read the PRD and TechSpec before reviewing code to understand intent. +- Review in severity order: critical first, low last. +- Focus on issues that matter. Skip style issues already caught by linters. +- Provide actionable suggestions: state the problem and what the fix looks like. +- Assign severity based on actual impact, not theoretical concern. +- Create one issue per file per distinct problem. +- If one problem spans multiple files, create one issue per affected file. +- Acknowledge well-implemented patterns; do not create issues for them. diff --git a/skills/risk-return-cost-of-capital/SKILL.md b/skills/risk-return-cost-of-capital/SKILL.md deleted file mode 100644 index 43d32e66..00000000 --- a/skills/risk-return-cost-of-capital/SKILL.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -name: risk-return-cost-of-capital -description: >- - Productize Finance engine for expected return, volatility, diversification, beta, - CAPM, excess-return regression, unlevering/relevering beta, WACC inputs, and - project-specific cost of capital. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Risk Return Cost Of Capital - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `risk-return-cost-of-capital` -- **Lifecycle**: Measure -- **Category**: Finance -- **Primary artifact**: Cost-of-capital analysis with risk basis, beta/CAPM/WACC inputs, calculation, interpretation, and warnings - -## Purpose - -Discount-rate and risk skill. Use it for cost of equity, beta, WACC inputs, expected -returns, volatility, diversification, and selecting a project-specific discount rate. - -## Core Formulas - -- `r_{t+1} = (P_{t+1} - P_t + Div_{t+1}) / P_t` -- `E[R] = sum(p_i * R_i)` -- `Var(R) = sum(p_i * (R_i - E[R])^2)` -- `SD(R) = sqrt(Var(R))` -- `E[R_p] = sum(x_i * E[R_i])` -- `Var(R_p) = sum_i sum_j x_i * x_j * Cov(R_i, R_j)` -- `rho_ij = Cov(R_i, R_j) / (sigma_i * sigma_j)` -- `beta_i = Cov(R_i, R_M) / Var(R_M)` -- `r_i = r_f + beta_i * (E[R_M] - r_f)` -- `WACC = E/(D+E) * r_E + D/(D+E) * (1 - T_c) * r_D` - -## Required Functions - -Use `$finance-modeling-kernel` for realized return, expected return, variance, -standard deviation, historical average return, portfolio expected return, portfolio -variance, covariance, correlation, beta, CAPM cost of equity, regression beta, -unlevered beta, relevered beta, and WACC. - -## Required Validation - -- Use long-term government bond rates for valuation risk-free rates. -- Use short-term risk-free rates for short-term performance measurement. -- Use excess returns when estimating beta by regression. -- Use market values for debt and equity in WACC. -- Warn if book-value weights are used. -- Warn if beta is estimated from too little data. -- Warn if a company beta is used for a different-risk project. -- Warn if total volatility is treated as priced risk for a diversified investor. -- Warn if the market risk premium and risk-free rate come from inconsistent markets. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. State the risk basis and why the discount rate matches the cash flows. diff --git a/skills/risk-return-cost-of-capital/SKILL.md.tmpl b/skills/risk-return-cost-of-capital/SKILL.md.tmpl deleted file mode 100644 index 1f2aea8b..00000000 --- a/skills/risk-return-cost-of-capital/SKILL.md.tmpl +++ /dev/null @@ -1,53 +0,0 @@ ---- -name: risk-return-cost-of-capital -description: >- - Productize Finance engine for expected return, volatility, diversification, beta, - CAPM, excess-return regression, unlevering/relevering beta, WACC inputs, and - project-specific cost of capital. ---- - -# Risk Return Cost Of Capital - -{{PRODUCTIZE_PREAMBLE}} - -## Purpose - -Discount-rate and risk skill. Use it for cost of equity, beta, WACC inputs, expected -returns, volatility, diversification, and selecting a project-specific discount rate. - -## Core Formulas - -- `r_{t+1} = (P_{t+1} - P_t + Div_{t+1}) / P_t` -- `E[R] = sum(p_i * R_i)` -- `Var(R) = sum(p_i * (R_i - E[R])^2)` -- `SD(R) = sqrt(Var(R))` -- `E[R_p] = sum(x_i * E[R_i])` -- `Var(R_p) = sum_i sum_j x_i * x_j * Cov(R_i, R_j)` -- `rho_ij = Cov(R_i, R_j) / (sigma_i * sigma_j)` -- `beta_i = Cov(R_i, R_M) / Var(R_M)` -- `r_i = r_f + beta_i * (E[R_M] - r_f)` -- `WACC = E/(D+E) * r_E + D/(D+E) * (1 - T_c) * r_D` - -## Required Functions - -Use `$finance-modeling-kernel` for realized return, expected return, variance, -standard deviation, historical average return, portfolio expected return, portfolio -variance, covariance, correlation, beta, CAPM cost of equity, regression beta, -unlevered beta, relevered beta, and WACC. - -## Required Validation - -- Use long-term government bond rates for valuation risk-free rates. -- Use short-term risk-free rates for short-term performance measurement. -- Use excess returns when estimating beta by regression. -- Use market values for debt and equity in WACC. -- Warn if book-value weights are used. -- Warn if beta is estimated from too little data. -- Warn if a company beta is used for a different-risk project. -- Warn if total volatility is treated as priced risk for a diversified investor. -- Warn if the market risk premium and risk-free rate come from inconsistent markets. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. State the risk basis and why the discount rate matches the cash flows. diff --git a/skills/risk-return-cost-of-capital/agents/openai.yaml b/skills/risk-return-cost-of-capital/agents/openai.yaml deleted file mode 100644 index 32821608..00000000 --- a/skills/risk-return-cost-of-capital/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Risk Return Cost Of Capital" - short_description: "Productize Finance engine for expected return, volatility, diversification, beta, CAPM, excess-return regression,..." - brand_color: "#0369A1" - default_prompt: "Use $risk-return-cost-of-capital with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/risk-return-cost-of-capital/productize.json b/skills/risk-return-cost-of-capital/productize.json deleted file mode 100644 index 020f195b..00000000 --- a/skills/risk-return-cost-of-capital/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Risk Return Cost Of Capital", - "category": "Finance", - "lifecycle": "Measure", - "tags": [ - "risk-return-cost-of-capital", - "cost-of-capital", - "capm", - "wacc", - "beta", - "discount-rate", - "risk-free-rate", - "market-risk-premium", - "portfolio-risk", - "systematic-risk", - "risk", - "return", - "cost", - "capital" - ], - "use_when": "Use when estimating cost of equity, beta, CAPM, WACC inputs, expected return, volatility, diversification, or project-specific discount rates.", - "do_not_use_when": "Do not use for full valuation or deal pricing unless the main missing input is the discount rate or risk basis.", - "output_artifact": "Cost-of-capital analysis with risk basis, beta/CAPM/WACC inputs, calculation, interpretation, and warnings", - "routing_signals": [ - "cost-of-capital", - "discount-rate", - "capm", - "wacc", - "cost-of-equity", - "beta", - "market-risk-premium", - "risk-free-rate", - "systematic-risk", - "project-specific-discount-rate", - "risk-return-cost-of-capital", - "risk", - "return", - "cost" - ], - "framework_fit": "Best when the key decision is what return or discount rate is appropriate for the cash-flow risk.", - "failure_modes": [ - "Uses book values instead of market values for WACC weights.", - "Uses total volatility as priced risk for a diversified investor.", - "Uses a company beta for a project in a materially different business.", - "Mixes risk-free rate and market risk premium from inconsistent markets." - ], - "examples": [ - { - "prompt": "Use $risk-return-cost-of-capital to estimate WACC for this valuation and explain whether the project should use the company WACC.", - "expected_artifact": "Cost-of-capital analysis with risk basis, beta/CAPM/WACC inputs, calculation, interpretation, and warnings" - } - ] -} diff --git a/skills/risky-assumption-prioritization-for-rapid-validation/SKILL.md b/skills/risky-assumption-prioritization-for-rapid-validation/SKILL.md deleted file mode 100644 index 666c3d23..00000000 --- a/skills/risky-assumption-prioritization-for-rapid-validation/SKILL.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -name: risky-assumption-prioritization-for-rapid-validation -description: >- - Risky assumption prioritization for rapid validation. Use when the user needs a product - workflow for user research related to risky assumption prioritization for rapid validation. - Trigger terms: user-research, assumptions, validation. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Risky assumption prioritization for rapid validation - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `risky-assumption-prioritization-for-rapid-validation` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Risky assumption prioritization for rapid validation research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Risky assumption prioritization for rapid validation**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{ASSUMPTIONS}}`: Plain-text assumption list (typically with Category, `Statement: We believe that...`, and `Impact if wrong:`). -</provided_inputs> - -GOAL -Prioritize assumptions by strategic risk using an Importance ร— Certainty model. -Success metric: -- Highest-risk assumptions are clearly ranked and justified. -- Scoring is consistent and traceable to assumption impact/evidence quality. -- Output follows strict plain-text structure exactly. - -CONSTRAINTS -- Focus only on prioritization; do not include validation plans, experiments, or recommendations. -- Use only provided assumptions; if Category is missing, infer one of: -- Desirability -- Feasibility -- Viability -- Usability -- Normalize duplicates before scoring (keep strongest impact framing). -- Score each assumption with: -- Importance (1-5): business/strategy impact if false. -- Certainty (1-5): strength of evidence assumption is true. -- Risk score = `Importance * (6 - Certainty)`. -- Use consistent scoring based on impact severity, blast radius, dependency risk, irreversibility/time sensitivity, and evidence quality. -- Perform decomposition/self-critique internally; report only final outcomes. -- Output must be plain text only (no XML/HTML tags, no code fences). - -FORMAT -Return exactly two sections in this order and nothing else: - -PRIORITIZATION -2x2 Summary (counts): HI/LC: x; HI/HC: y; LI/LC: z; LI/HC: w - -Top Risks (HI/LC), ranked by Risk score (highest first). For each item, include exactly: -Assumption: "We believe that ..." (verbatim) -Category: [Desirability | Feasibility | Viability | Usability] -Importance: [1-5] -Certainty: [1-5] -Risk score: [number] -Rationale: [max 2 short bullets referencing severity, blast radius, dependency, irreversibility, or evidence quality] - -Full Ranked List: All assumptions sorted by Risk score (desc). Each line: -[Rank]. [Category] - Importance:[x] Certainty:[y] Risk:[z] - "We believe that ..." - -QUALITY CHECK -- 3-6 concise bullets summarizing self-critique outcomes (for example: duplicate merges, re-scored items, category balance, scoring ambiguities). -- Do not include chain-of-thought or step-by-step internal reasoning. - -FAILURE -- Output includes anything beyond the two required sections or wrong section order. -- Output contains XML/HTML tags, angle-bracket wrappers, or code blocks. -- Includes validation plans/recommendations instead of prioritization-only results. -- Top Risks entries are missing required fields. -- Risk formula is not applied consistently or rankings are not sorted by Risk score descending. -- `Assumption` text is not preserved verbatim where required. -- Quality check is missing, too short (<3 bullets), or exposes internal reasoning. diff --git a/skills/risky-assumption-prioritization-for-rapid-validation/SKILL.md.tmpl b/skills/risky-assumption-prioritization-for-rapid-validation/SKILL.md.tmpl deleted file mode 100644 index 6864380d..00000000 --- a/skills/risky-assumption-prioritization-for-rapid-validation/SKILL.md.tmpl +++ /dev/null @@ -1,80 +0,0 @@ ---- -name: risky-assumption-prioritization-for-rapid-validation -description: >- - Risky assumption prioritization for rapid validation. Use when the user needs a product - workflow for user research related to risky assumption prioritization for rapid validation. - Trigger terms: user-research, assumptions, validation. ---- -# Risky assumption prioritization for rapid validation - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Risky assumption prioritization for rapid validation**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{ASSUMPTIONS}}`: Plain-text assumption list (typically with Category, `Statement: We believe that...`, and `Impact if wrong:`). -</provided_inputs> - -GOAL -Prioritize assumptions by strategic risk using an Importance ร— Certainty model. -Success metric: -- Highest-risk assumptions are clearly ranked and justified. -- Scoring is consistent and traceable to assumption impact/evidence quality. -- Output follows strict plain-text structure exactly. - -CONSTRAINTS -- Focus only on prioritization; do not include validation plans, experiments, or recommendations. -- Use only provided assumptions; if Category is missing, infer one of: -- Desirability -- Feasibility -- Viability -- Usability -- Normalize duplicates before scoring (keep strongest impact framing). -- Score each assumption with: -- Importance (1-5): business/strategy impact if false. -- Certainty (1-5): strength of evidence assumption is true. -- Risk score = `Importance * (6 - Certainty)`. -- Use consistent scoring based on impact severity, blast radius, dependency risk, irreversibility/time sensitivity, and evidence quality. -- Perform decomposition/self-critique internally; report only final outcomes. -- Output must be plain text only (no XML/HTML tags, no code fences). - -FORMAT -Return exactly two sections in this order and nothing else: - -PRIORITIZATION -2x2 Summary (counts): HI/LC: x; HI/HC: y; LI/LC: z; LI/HC: w - -Top Risks (HI/LC), ranked by Risk score (highest first). For each item, include exactly: -Assumption: "We believe that ..." (verbatim) -Category: [Desirability | Feasibility | Viability | Usability] -Importance: [1-5] -Certainty: [1-5] -Risk score: [number] -Rationale: [max 2 short bullets referencing severity, blast radius, dependency, irreversibility, or evidence quality] - -Full Ranked List: All assumptions sorted by Risk score (desc). Each line: -[Rank]. [Category] - Importance:[x] Certainty:[y] Risk:[z] - "We believe that ..." - -QUALITY CHECK -- 3-6 concise bullets summarizing self-critique outcomes (for example: duplicate merges, re-scored items, category balance, scoring ambiguities). -- Do not include chain-of-thought or step-by-step internal reasoning. - -FAILURE -- Output includes anything beyond the two required sections or wrong section order. -- Output contains XML/HTML tags, angle-bracket wrappers, or code blocks. -- Includes validation plans/recommendations instead of prioritization-only results. -- Top Risks entries are missing required fields. -- Risk formula is not applied consistently or rankings are not sorted by Risk score descending. -- `Assumption` text is not preserved verbatim where required. -- Quality check is missing, too short (<3 bullets), or exposes internal reasoning. diff --git a/skills/risky-assumption-prioritization-for-rapid-validation/agents/openai.yaml b/skills/risky-assumption-prioritization-for-rapid-validation/agents/openai.yaml deleted file mode 100644 index 889ddc61..00000000 --- a/skills/risky-assumption-prioritization-for-rapid-validation/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Risky assumption prioritization for rapid validation" - short_description: "Risky assumption prioritization for rapid validation. Use when the user needs a product workflow for user research..." - brand_color: "#0D9488" - default_prompt: "Use $risky-assumption-prioritization-for-rapid-validation with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/risky-assumption-prioritization-for-rapid-validation/productize.json b/skills/risky-assumption-prioritization-for-rapid-validation/productize.json deleted file mode 100644 index 70e51d44..00000000 --- a/skills/risky-assumption-prioritization-for-rapid-validation/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Risky assumption prioritization for rapid validation", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "risky-assumption-prioritization-for-rapid-validation", - "risky", - "assumption", - "prioritization", - "rapid", - "validation" - ], - "use_when": "Risky assumption prioritization for rapid validation. Use when the user needs a product workflow for user research related to risky assumption prioritization for rapid validation. Trigger terms: user-research, assumptions, validation.", - "do_not_use_when": "Do not use Risky assumption prioritization for rapid validation when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Risky assumption prioritization for rapid validation research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "risky-assumption-prioritization-for-rapid-validation", - "risky", - "assumption", - "prioritization", - "rapid", - "validation" - ], - "framework_fit": "Risky assumption prioritization for rapid validation fits Discovery work in the Discover lifecycle when the user needs Risky assumption prioritization for rapid validation research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Risky assumption prioritization for rapid validation research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Risky assumption prioritization for rapid validation as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Risky assumption prioritization for rapid validation when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $risky-assumption-prioritization-for-rapid-validation to turn this risky context into a decision-ready Risky assumption prioritization for rapid validation research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Risky assumption prioritization for rapid validation research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/roadmap-update/SKILL.md b/skills/roadmap-update/SKILL.md deleted file mode 100644 index 545d8ccb..00000000 --- a/skills/roadmap-update/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: roadmap-update -description: >- - Update, create, or reprioritize a product roadmap. Use when adding an initiative, deciding - what moves to make room, shifting priorities after new information, moving timelines after a - dependency slip, or building a Now/Next/Later view. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Roadmap Update - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `roadmap-update` -- **Lifecycle**: Strategize -- **Category**: Stakeholder Communication -- **Primary artifact**: Roadmap decision memo with options, tradeoffs, and updated Now/Next/Later plan - -Update, create, or reprioritize a product roadmap. - -## Argument Hint - -`<update description>` - -## Usage - -```text -/roadmap-update $ARGUMENTS -``` - -## Workflow - -### 1. Understand Current State - -If a project tracker is connected, pull roadmap items, status, owners, target dates, overdue work, at-risk items, and recently completed work. - -If no tracker is connected, ask the user to paste or describe the roadmap in any format. - -### 2. Determine Operation - -Identify the requested operation: - -- **Add item**: gather name, description, priority, effort, timeframe, owner, dependencies, and what moves to make room. -- **Update status**: not started, in progress, at risk, blocked, completed, cut. For at-risk or blocked, capture blocker and mitigation. -- **Reprioritize**: ask what changed, apply a framework if useful, and show before/after. -- **Move timeline**: ask why, identify downstream impacts, and flag hard-deadline risks. -- **Create roadmap**: ask timeframe, format, goals, themes, and initiative list. - -### 3. Choose Format - -Use the format that fits the audience: -- Now / Next / Later for broad communication. -- Quarterly themes for strategy alignment. -- OKR-aligned roadmap for metric-backed planning. -- Timeline view for execution planning with dependencies. - -### 4. Generate Roadmap Summary - -Include: -- Status overview: counts in progress, completed, at risk, blocked. -- Roadmap items grouped by timeframe or theme. -- Risks and dependencies with owners and need-by dates. -- Changes this update: added, removed, reprioritized, timeline shifts, status changes. - -Use tables where helpful. - -### 5. Prioritization Tools - -Use only when they clarify tradeoffs: -- RICE: Reach x Impact x Confidence / Effort. -- MoSCoW: Must, Should, Could, Won't. -- ICE: Impact x Confidence x Ease. -- Value vs Effort: quick wins, big bets, fill-ins, avoid. - -## Rules - -- Roadmaps are capacity-constrained. When adding something, ask what comes off or moves. -- Surface dependency risk early. -- Communicate changes by naming what changed, why, what tradeoff was made, and who is affected. -- Do not create false precision for work that is still directional. diff --git a/skills/roadmap-update/SKILL.md.tmpl b/skills/roadmap-update/SKILL.md.tmpl deleted file mode 100644 index f1c14ddd..00000000 --- a/skills/roadmap-update/SKILL.md.tmpl +++ /dev/null @@ -1,73 +0,0 @@ ---- -name: roadmap-update -description: >- - Update, create, or reprioritize a product roadmap. Use when adding an initiative, deciding - what moves to make room, shifting priorities after new information, moving timelines after a - dependency slip, or building a Now/Next/Later view. ---- -# Roadmap Update - -{{PRODUCTIZE_PREAMBLE}} - -Update, create, or reprioritize a product roadmap. - -## Argument Hint - -`<update description>` - -## Usage - -```text -/roadmap-update $ARGUMENTS -``` - -## Workflow - -### 1. Understand Current State - -If a project tracker is connected, pull roadmap items, status, owners, target dates, overdue work, at-risk items, and recently completed work. - -If no tracker is connected, ask the user to paste or describe the roadmap in any format. - -### 2. Determine Operation - -Identify the requested operation: - -- **Add item**: gather name, description, priority, effort, timeframe, owner, dependencies, and what moves to make room. -- **Update status**: not started, in progress, at risk, blocked, completed, cut. For at-risk or blocked, capture blocker and mitigation. -- **Reprioritize**: ask what changed, apply a framework if useful, and show before/after. -- **Move timeline**: ask why, identify downstream impacts, and flag hard-deadline risks. -- **Create roadmap**: ask timeframe, format, goals, themes, and initiative list. - -### 3. Choose Format - -Use the format that fits the audience: -- Now / Next / Later for broad communication. -- Quarterly themes for strategy alignment. -- OKR-aligned roadmap for metric-backed planning. -- Timeline view for execution planning with dependencies. - -### 4. Generate Roadmap Summary - -Include: -- Status overview: counts in progress, completed, at risk, blocked. -- Roadmap items grouped by timeframe or theme. -- Risks and dependencies with owners and need-by dates. -- Changes this update: added, removed, reprioritized, timeline shifts, status changes. - -Use tables where helpful. - -### 5. Prioritization Tools - -Use only when they clarify tradeoffs: -- RICE: Reach x Impact x Confidence / Effort. -- MoSCoW: Must, Should, Could, Won't. -- ICE: Impact x Confidence x Ease. -- Value vs Effort: quick wins, big bets, fill-ins, avoid. - -## Rules - -- Roadmaps are capacity-constrained. When adding something, ask what comes off or moves. -- Surface dependency risk early. -- Communicate changes by naming what changed, why, what tradeoff was made, and who is affected. -- Do not create false precision for work that is still directional. diff --git a/skills/roadmap-update/agents/openai.yaml b/skills/roadmap-update/agents/openai.yaml deleted file mode 100644 index 465c1c34..00000000 --- a/skills/roadmap-update/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Roadmap Update" - short_description: "Update, create, or reprioritize a product roadmap. Use when adding an initiative, deciding what moves to make room,..." - brand_color: "#0891B2" - default_prompt: "Use $roadmap-update with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/roadmap-update/productize.json b/skills/roadmap-update/productize.json deleted file mode 100644 index b047a850..00000000 --- a/skills/roadmap-update/productize.json +++ /dev/null @@ -1,47 +0,0 @@ -{ - "title": "Roadmap Update", - "category": "Stakeholder Communication", - "tags": [ - "roadmap", - "prioritization", - "now-next-later", - "dependencies", - "capacity", - "stakeholders", - "roadmap-update", - "update", - "create", - "reprioritize", - "use", - "adding", - "stakeholder", - "communication" - ], - "lifecycle": "Strategize", - "use_when": "Update, create, or reprioritize a product roadmap. Use when adding an initiative, deciding what moves to make room, shifting priorities after new information, moving timelines after a dependency slip, or building a Now/Next/Later view.", - "do_not_use_when": "Do not use Roadmap Update when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Roadmap decision memo with options, tradeoffs, and updated Now/Next/Later plan", - "routing_signals": [ - "roadmap-update", - "roadmap", - "update", - "create", - "reprioritize", - "use", - "adding", - "stakeholder", - "communication" - ], - "framework_fit": "Appropriate when an existing roadmap needs reprioritization because of new customer evidence, sales pressure, capacity limits, reliability work, or stakeholder tradeoffs.", - "failure_modes": [ - "Produces Roadmap decision memo with options, tradeoffs, and updated Now/Next/Later plan without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Roadmap Update as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Roadmap Update when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $roadmap-update to turn this roadmap context into a decision-ready Roadmap decision memo with options, tradeoffs, and updated Now/Next/Later plan.", - "expected_artifact": "Roadmap decision memo with options, tradeoffs, and updated Now/Next/Later plan" - } - ] -} diff --git a/skills/robust-experiment-design-from-goals-and-systems/SKILL.md b/skills/robust-experiment-design-from-goals-and-systems/SKILL.md deleted file mode 100644 index d8800c48..00000000 --- a/skills/robust-experiment-design-from-goals-and-systems/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: robust-experiment-design-from-goals-and-systems -description: >- - Robust experiment design from goals and systems. Use when the user needs a product workflow - for user research related to robust experiment design from goals and systems. Trigger terms: - user-research, experiments, validation. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Robust experiment design from goals and systems - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `robust-experiment-design-from-goals-and-systems` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Robust experiment design from goals and systems research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Robust experiment design from goals and systems**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{GOAL}}`: Outcome to achieve or measure. -- `{{SYSTEM}}`: Context/environment where goal is pursued. -- `{{EXPERIMENT_TEMPLATE}}` (optional): Required template for experiment design output. -</provided_inputs> - -GOAL -Design a robust, factor-based experiment program that tests what drives the target goal within the specified system. -Success metric: -- Key causal factors are identified and explained. -- Each factor has a testable experiment design with rigorous controls and measurement. -- If a template is provided, the final design is adapted to that template without losing rigor. - -CONSTRAINTS -- Use only provided inputs; if missing/ambiguous details exist, state explicit assumptions. -- First decompose the goal/system into influential factors before proposing experiments. -- For each factor, define one concrete experiment including: -- Hypothesis -- Independent variable(s) -- Dependent variable(s) -- Control and experimental groups (or justified alternative when groups are not applicable) -- Measurement method(s) and success metric(s) -- Confounding variables and mitigation controls -- Ensure experiments are specific, feasible, and directly linked to `{{GOAL}}`. -- If `{{EXPERIMENT_TEMPLATE}}` is provided, produce an adapted version that maps identified factors/experiments into that structure. -- Avoid generic methods and unsupported claims. - -FORMAT -Return exactly this structure: - -<experiment_design> - -<factor_breakdown> -[Numbered list of key factors, each with a brief explanation of why it may influence the goal in this system.] -</factor_breakdown> - -<experiment_program> -[For each factor, include: -- Factor -- Hypothesis -- Independent variable(s) -- Dependent variable(s) -- Control group / baseline -- Experimental group(s) / treatment(s) -- Measurement method and timeline -- Confounding variables and control plan -- Expected decision rule (what result confirms/refutes hypothesis)] -</experiment_program> - -<template_design> -[If `{{EXPERIMENT_TEMPLATE}}` is provided, present the adapted experiment design using that template; otherwise write `No template provided.`] -</template_design> - -<assumptions> -[List explicit assumptions made due to unclear or missing inputs; write `None.` if no assumptions were required.] -</assumptions> - -</experiment_design> - -FAILURE -- Output misses required top-level tags or required experiment fields. -- Factors are generic, not tied to `{{GOAL}}`/`{{SYSTEM}}`, or missing rationale. -- Experiments lack testability (unclear variables, no control/baseline, no measurable outcomes). -- Confounders are ignored or not controlled. -- Template is provided but not used in `<template_design>`. -- Assumptions are needed but not explicitly listed. diff --git a/skills/robust-experiment-design-from-goals-and-systems/SKILL.md.tmpl b/skills/robust-experiment-design-from-goals-and-systems/SKILL.md.tmpl deleted file mode 100644 index c3a686d1..00000000 --- a/skills/robust-experiment-design-from-goals-and-systems/SKILL.md.tmpl +++ /dev/null @@ -1,90 +0,0 @@ ---- -name: robust-experiment-design-from-goals-and-systems -description: >- - Robust experiment design from goals and systems. Use when the user needs a product workflow - for user research related to robust experiment design from goals and systems. Trigger terms: - user-research, experiments, validation. ---- -# Robust experiment design from goals and systems - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Robust experiment design from goals and systems**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- `{{GOAL}}`: Outcome to achieve or measure. -- `{{SYSTEM}}`: Context/environment where goal is pursued. -- `{{EXPERIMENT_TEMPLATE}}` (optional): Required template for experiment design output. -</provided_inputs> - -GOAL -Design a robust, factor-based experiment program that tests what drives the target goal within the specified system. -Success metric: -- Key causal factors are identified and explained. -- Each factor has a testable experiment design with rigorous controls and measurement. -- If a template is provided, the final design is adapted to that template without losing rigor. - -CONSTRAINTS -- Use only provided inputs; if missing/ambiguous details exist, state explicit assumptions. -- First decompose the goal/system into influential factors before proposing experiments. -- For each factor, define one concrete experiment including: -- Hypothesis -- Independent variable(s) -- Dependent variable(s) -- Control and experimental groups (or justified alternative when groups are not applicable) -- Measurement method(s) and success metric(s) -- Confounding variables and mitigation controls -- Ensure experiments are specific, feasible, and directly linked to `{{GOAL}}`. -- If `{{EXPERIMENT_TEMPLATE}}` is provided, produce an adapted version that maps identified factors/experiments into that structure. -- Avoid generic methods and unsupported claims. - -FORMAT -Return exactly this structure: - -<experiment_design> - -<factor_breakdown> -[Numbered list of key factors, each with a brief explanation of why it may influence the goal in this system.] -</factor_breakdown> - -<experiment_program> -[For each factor, include: -- Factor -- Hypothesis -- Independent variable(s) -- Dependent variable(s) -- Control group / baseline -- Experimental group(s) / treatment(s) -- Measurement method and timeline -- Confounding variables and control plan -- Expected decision rule (what result confirms/refutes hypothesis)] -</experiment_program> - -<template_design> -[If `{{EXPERIMENT_TEMPLATE}}` is provided, present the adapted experiment design using that template; otherwise write `No template provided.`] -</template_design> - -<assumptions> -[List explicit assumptions made due to unclear or missing inputs; write `None.` if no assumptions were required.] -</assumptions> - -</experiment_design> - -FAILURE -- Output misses required top-level tags or required experiment fields. -- Factors are generic, not tied to `{{GOAL}}`/`{{SYSTEM}}`, or missing rationale. -- Experiments lack testability (unclear variables, no control/baseline, no measurable outcomes). -- Confounders are ignored or not controlled. -- Template is provided but not used in `<template_design>`. -- Assumptions are needed but not explicitly listed. diff --git a/skills/robust-experiment-design-from-goals-and-systems/agents/openai.yaml b/skills/robust-experiment-design-from-goals-and-systems/agents/openai.yaml deleted file mode 100644 index a5ad3de7..00000000 --- a/skills/robust-experiment-design-from-goals-and-systems/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Robust experiment design from goals and systems" - short_description: "Robust experiment design from goals and systems. Use when the user needs a product workflow for user research..." - brand_color: "#0D9488" - default_prompt: "Use $robust-experiment-design-from-goals-and-systems with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/robust-experiment-design-from-goals-and-systems/productize.json b/skills/robust-experiment-design-from-goals-and-systems/productize.json deleted file mode 100644 index 4dd9c627..00000000 --- a/skills/robust-experiment-design-from-goals-and-systems/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Robust experiment design from goals and systems", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "robust-experiment-design-from-goals-and-systems", - "robust", - "experiment", - "design", - "goals", - "systems" - ], - "use_when": "Robust experiment design from goals and systems. Use when the user needs a product workflow for user research related to robust experiment design from goals and systems. Trigger terms: user-research, experiments, validation.", - "do_not_use_when": "Do not use Robust experiment design from goals and systems when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Robust experiment design from goals and systems research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "robust-experiment-design-from-goals-and-systems", - "robust", - "experiment", - "design", - "goals", - "systems" - ], - "framework_fit": "Robust experiment design from goals and systems fits Discovery work in the Discover lifecycle when the user needs Robust experiment design from goals and systems research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Robust experiment design from goals and systems research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Robust experiment design from goals and systems as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Robust experiment design from goals and systems when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $robust-experiment-design-from-goals-and-systems to turn this robust context into a decision-ready Robust experiment design from goals and systems research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Robust experiment design from goals and systems research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/role-identity-decision-making-map/SKILL.md b/skills/role-identity-decision-making-map/SKILL.md deleted file mode 100644 index c4c21319..00000000 --- a/skills/role-identity-decision-making-map/SKILL.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -name: role-identity-decision-making-map -description: >- - Map how role identity, organizational identity, in-group/out-group dynamics, and role - expectations shape a product or innovation decision. Use when the user needs to understand - why stakeholders decide according to role pressure, identity, or social context. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Role Identity Decision Making Map - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `role-identity-decision-making-map` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Role identity decision-making map with stakeholder roles, logic of appropriateness, social context risks, decision impact, and process adjustments - -Use this skill when a decision is being shaped by roles, identity, group membership, or -organizational self-image. It is especially useful for cross-functional product decisions, -innovation resistance, transformation work, roadmap tradeoffs, and decisions where people -argue from their "hat" rather than from the evidence. - -## Decision-Making Principles - -- People classify situations through role identities and expected role behavior. -- Role identity creates a "logic of appropriateness": what someone feels they should do - because of their function, hierarchy, profession, or organizational role. -- Role salience changes with context, timing, habits, incentives, and pressure from others. -- Cross-functional teams are not automatically better decision makers; role conflict can - reduce integration or produce defensive information processing. -- Organizational identity can guide good decisions, but strong identity can block innovation - and strategic change. -- Social categorization creates in-groups and out-groups, changing trust, similarity, - evidence weighting, and willingness to support change. - -## Workflow - -1. Define the decision and stakeholders. -2. Identify each stakeholder's formal role, informal role, salient identity, and expected behavior. -3. Map role pressure, incentives, status risk, and identity threat. -4. Identify in-group/out-group dynamics and organizational identity constraints. -5. Predict how each role identity will search for, interpret, and weight information. -6. Recommend role reframing, process changes, and evidence framing to improve the decision. - -## Output Contract - -Return: - -```markdown -# Role Identity Decision Making Map - -## 1. Decision Context -Decision: -Decision owner: -Stakeholders: -Why role identity matters: - -## 2. Role Identity Map -| Stakeholder | Formal role | Informal role | Salient identity | Expected role behavior | Decision pressure | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -## 3. Logic Of Appropriateness -Role-based assumptions: -Unwritten rules: -What each stakeholder feels they must protect: -Role segmenters vs integrators: - -## 4. Social Context Risks -In-groups: -Out-groups: -Identity threat: -Organizational identity constraint: -Innovation resistance: - -## 5. Decision Impact -Information each role will seek: -Information each role may discount: -Likely alliances: -Likely blockers: -Where evidence may be distorted: - -## 6. Decision Process Adjustments -Role reframing: -Different hats to assign: -Private input needed: -Evidence framing: -Psychological safety needs: -Decision owner move: - -## 7. Recommendation -Best next move: -Who to pre-wire: -What to say: -What to avoid: -``` - -## Failure Modes - -- Reduces stakeholder behavior to power/interest only, ignoring role identity and social context. -- Treats cross-functional participation as automatically sufficient. -- Speculates about motives without grounding in role, incentive, behavior, or context. -- Omits organizational identity and in-group/out-group effects. diff --git a/skills/role-identity-decision-making-map/SKILL.md.tmpl b/skills/role-identity-decision-making-map/SKILL.md.tmpl deleted file mode 100644 index 152a5405..00000000 --- a/skills/role-identity-decision-making-map/SKILL.md.tmpl +++ /dev/null @@ -1,97 +0,0 @@ ---- -name: role-identity-decision-making-map -description: >- - Map how role identity, organizational identity, in-group/out-group dynamics, and role - expectations shape a product or innovation decision. Use when the user needs to understand - why stakeholders decide according to role pressure, identity, or social context. ---- -# Role Identity Decision Making Map - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when a decision is being shaped by roles, identity, group membership, or -organizational self-image. It is especially useful for cross-functional product decisions, -innovation resistance, transformation work, roadmap tradeoffs, and decisions where people -argue from their "hat" rather than from the evidence. - -## Decision-Making Principles - -- People classify situations through role identities and expected role behavior. -- Role identity creates a "logic of appropriateness": what someone feels they should do - because of their function, hierarchy, profession, or organizational role. -- Role salience changes with context, timing, habits, incentives, and pressure from others. -- Cross-functional teams are not automatically better decision makers; role conflict can - reduce integration or produce defensive information processing. -- Organizational identity can guide good decisions, but strong identity can block innovation - and strategic change. -- Social categorization creates in-groups and out-groups, changing trust, similarity, - evidence weighting, and willingness to support change. - -## Workflow - -1. Define the decision and stakeholders. -2. Identify each stakeholder's formal role, informal role, salient identity, and expected behavior. -3. Map role pressure, incentives, status risk, and identity threat. -4. Identify in-group/out-group dynamics and organizational identity constraints. -5. Predict how each role identity will search for, interpret, and weight information. -6. Recommend role reframing, process changes, and evidence framing to improve the decision. - -## Output Contract - -Return: - -```markdown -# Role Identity Decision Making Map - -## 1. Decision Context -Decision: -Decision owner: -Stakeholders: -Why role identity matters: - -## 2. Role Identity Map -| Stakeholder | Formal role | Informal role | Salient identity | Expected role behavior | Decision pressure | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -## 3. Logic Of Appropriateness -Role-based assumptions: -Unwritten rules: -What each stakeholder feels they must protect: -Role segmenters vs integrators: - -## 4. Social Context Risks -In-groups: -Out-groups: -Identity threat: -Organizational identity constraint: -Innovation resistance: - -## 5. Decision Impact -Information each role will seek: -Information each role may discount: -Likely alliances: -Likely blockers: -Where evidence may be distorted: - -## 6. Decision Process Adjustments -Role reframing: -Different hats to assign: -Private input needed: -Evidence framing: -Psychological safety needs: -Decision owner move: - -## 7. Recommendation -Best next move: -Who to pre-wire: -What to say: -What to avoid: -``` - -## Failure Modes - -- Reduces stakeholder behavior to power/interest only, ignoring role identity and social context. -- Treats cross-functional participation as automatically sufficient. -- Speculates about motives without grounding in role, incentive, behavior, or context. -- Omits organizational identity and in-group/out-group effects. diff --git a/skills/role-identity-decision-making-map/agents/openai.yaml b/skills/role-identity-decision-making-map/agents/openai.yaml deleted file mode 100644 index cede9577..00000000 --- a/skills/role-identity-decision-making-map/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Role Identity Decision Making Map" - short_description: "Map how role identity, organizational identity, in-group/out-group dynamics, and role expectations shape a product..." - brand_color: "#7C2D12" - default_prompt: "Use $role-identity-decision-making-map with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/role-identity-decision-making-map/productize.json b/skills/role-identity-decision-making-map/productize.json deleted file mode 100644 index 331155fc..00000000 --- a/skills/role-identity-decision-making-map/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Role Identity Decision Making Map", - "category": "Decision Making", - "lifecycle": "Align", - "tags": [ - "role-identity", - "decision-making", - "logic-of-appropriateness", - "organizational-identity", - "social-categorization", - "in-group", - "out-group", - "role-pressure", - "cross-functional-teams", - "innovation-resistance", - "role-identity-decision-making-map", - "role", - "identity", - "decision" - ], - "use_when": "Use when a product, innovation, roadmap, transformation, or strategic decision is shaped by role expectations, hierarchy, function, organizational identity, in-group/out-group dynamics, or cross-functional role conflict.", - "do_not_use_when": "Do not use for a generic power-interest stakeholder map, hidden-agenda speculation, or group meeting process unless role identity and social categorization are central to the decision.", - "output_artifact": "Role identity decision-making map with stakeholder roles, logic of appropriateness, social context risks, decision impact, and process adjustments", - "routing_signals": [ - "role-identity", - "logic-of-appropriateness", - "organizational-identity", - "social-categorization", - "in-group", - "out-group", - "role-pressure", - "wearing-hats", - "cross-functional-decision", - "innovation-resistance", - "this-is-how-we-have-always-done-it", - "role-identity-decision-making-map", - "role", - "identity" - ], - "framework_fit": "Best when the decision is blocked or distorted by role expectations, identity protection, organizational self-image, or social categorization.", - "failure_modes": [ - "Maps only power and interest while missing role identity.", - "Speculates about hidden motives without grounding in observable role context.", - "Fails to identify in-group/out-group effects and organizational identity constraints.", - "Omits concrete process adjustments to improve the decision." - ], - "examples": [ - { - "prompt": "Use $role-identity-decision-making-map to understand why engineering, sales, and legal keep interpreting the same roadmap decision differently.", - "expected_artifact": "Role identity decision-making map with stakeholder roles, logic of appropriateness, social context risks, decision impact, and process adjustments" - } - ] -} diff --git a/skills/root-cause-and-consequence-analysis-from-a-question/SKILL.md b/skills/root-cause-and-consequence-analysis-from-a-question/SKILL.md deleted file mode 100644 index 97943094..00000000 --- a/skills/root-cause-and-consequence-analysis-from-a-question/SKILL.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -name: root-cause-and-consequence-analysis-from-a-question -description: >- - Root cause and consequence analysis from a question. Use when the user needs a product - workflow for decision making related to root cause and consequence analysis from a question. - Trigger terms: pm, decision-making, analysis, root-causes, reasoning. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Root cause and consequence analysis from a question - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `root-cause-and-consequence-analysis-from-a-question` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: Root cause and consequence analysis from a question decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **Root cause and consequence analysis from a question**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{INITIAL_QUESTION}} -</provided_inputs> - -GOAL -Identify plausible root causes and downstream consequences of `INITIAL_QUESTION` using recursive why-analysis and first-principles reasoning. -Success metric: -- Performs a deep why-chain (target depth: at least 5 levels or until a defensible root cause boundary). -- Explores consequence orders from first through fifth (positive and negative where plausible). -- Distinguishes assumptions from inferred facts and flags logic gaps. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis layers: - 1. Recursive why-analysis. - 2. Consequence chain (1st to 5th order). - 3. First-principles reconstruction. -- For why-analysis, explore parallel branches when multiple plausible causes emerge. -- For consequence analysis, include both upside and downside outcomes when credible. -- Keep reasoning neutral and explicit; avoid unsupported certainty. -- Clearly label assumptions and unknowns. - -FORMAT -Return exactly this structure: - -<analysis> -<root_causes> -[List your "Why?" questions and answers here, showing the progression to the root cause(s)] -</root_causes> - -<consequences> -[Describe the potential consequences here, from first-order to fifth-order] -</consequences> - -<first_principles> -[Present your first principles analysis here, including fundamental truths, questioned assumptions, and any identified gaps] -</first_principles> - -<conclusion> -[Summarize your key findings and insights] -</conclusion> -</analysis> - -FAILURE -- Required schema is missing or malformed. -- Why-analysis is shallow (no meaningful depth/branching) or lacks root-cause rationale. -- Consequence analysis does not cover first through fifth order. -- First-principles section does not separate assumptions from fundamentals. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/root-cause-and-consequence-analysis-from-a-question/SKILL.md.tmpl b/skills/root-cause-and-consequence-analysis-from-a-question/SKILL.md.tmpl deleted file mode 100644 index dfb3e957..00000000 --- a/skills/root-cause-and-consequence-analysis-from-a-question/SKILL.md.tmpl +++ /dev/null @@ -1,75 +0,0 @@ ---- -name: root-cause-and-consequence-analysis-from-a-question -description: >- - Root cause and consequence analysis from a question. Use when the user needs a product - workflow for decision making related to root cause and consequence analysis from a question. - Trigger terms: pm, decision-making, analysis, root-causes, reasoning. ---- -# Root cause and consequence analysis from a question - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Root cause and consequence analysis from a question**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{INITIAL_QUESTION}} -</provided_inputs> - -GOAL -Identify plausible root causes and downstream consequences of `INITIAL_QUESTION` using recursive why-analysis and first-principles reasoning. -Success metric: -- Performs a deep why-chain (target depth: at least 5 levels or until a defensible root cause boundary). -- Explores consequence orders from first through fifth (positive and negative where plausible). -- Distinguishes assumptions from inferred facts and flags logic gaps. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis layers: - 1. Recursive why-analysis. - 2. Consequence chain (1st to 5th order). - 3. First-principles reconstruction. -- For why-analysis, explore parallel branches when multiple plausible causes emerge. -- For consequence analysis, include both upside and downside outcomes when credible. -- Keep reasoning neutral and explicit; avoid unsupported certainty. -- Clearly label assumptions and unknowns. - -FORMAT -Return exactly this structure: - -<analysis> -<root_causes> -[List your "Why?" questions and answers here, showing the progression to the root cause(s)] -</root_causes> - -<consequences> -[Describe the potential consequences here, from first-order to fifth-order] -</consequences> - -<first_principles> -[Present your first principles analysis here, including fundamental truths, questioned assumptions, and any identified gaps] -</first_principles> - -<conclusion> -[Summarize your key findings and insights] -</conclusion> -</analysis> - -FAILURE -- Required schema is missing or malformed. -- Why-analysis is shallow (no meaningful depth/branching) or lacks root-cause rationale. -- Consequence analysis does not cover first through fifth order. -- First-principles section does not separate assumptions from fundamentals. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/root-cause-and-consequence-analysis-from-a-question/agents/openai.yaml b/skills/root-cause-and-consequence-analysis-from-a-question/agents/openai.yaml deleted file mode 100644 index bcca4481..00000000 --- a/skills/root-cause-and-consequence-analysis-from-a-question/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Root cause and consequence analysis from a question" - short_description: "Root cause and consequence analysis from a question. Use when the user needs a product workflow for decision making..." - brand_color: "#059669" - default_prompt: "Use $root-cause-and-consequence-analysis-from-a-question with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/root-cause-and-consequence-analysis-from-a-question/productize.json b/skills/root-cause-and-consequence-analysis-from-a-question/productize.json deleted file mode 100644 index 25044cdc..00000000 --- a/skills/root-cause-and-consequence-analysis-from-a-question/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Root cause and consequence analysis from a question", - "category": "Strategy", - "lifecycle": "Think", - "tags": [ - "root-cause-and-consequence-analysis-from-a-question", - "root", - "cause", - "consequence", - "question", - "decision", - "making" - ], - "use_when": "Root cause and consequence analysis from a question. Use when the user needs a product workflow for decision making related to root cause and consequence analysis from a question. Trigger terms: pm, decision-making, analysis, root-causes, reasoning.", - "do_not_use_when": "Do not use Root cause and consequence analysis from a question when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Root cause and consequence analysis from a question decision-framing brief with issue tree, assumptions, options, and recommended next step", - "routing_signals": [ - "root-cause-and-consequence-analysis-from-a-question", - "root", - "cause", - "consequence", - "question", - "decision", - "making" - ], - "framework_fit": "Root cause and consequence analysis from a question fits Strategy work in the Think lifecycle when the user needs Root cause and consequence analysis from a question decision-framing brief with issue tree, assumptions, options, and recommended next step and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Root cause and consequence analysis from a question decision-framing brief with issue tree, assumptions, options, and recommended next step without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Root cause and consequence analysis from a question as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Root cause and consequence analysis from a question when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $root-cause-and-consequence-analysis-from-a-question to turn this root context into a decision-ready Root cause and consequence analysis from a question decision-framing brief with issue tree, assumptions, options, and recommended next step.", - "expected_artifact": "Root cause and consequence analysis from a question decision-framing brief with issue tree, assumptions, options, and recommended next step" - } - ] -} diff --git a/skills/scope-defense-using-time-cost-tradeoff-analysis/SKILL.md b/skills/scope-defense-using-time-cost-tradeoff-analysis/SKILL.md deleted file mode 100644 index 0f65c08b..00000000 --- a/skills/scope-defense-using-time-cost-tradeoff-analysis/SKILL.md +++ /dev/null @@ -1,775 +0,0 @@ ---- -name: scope-defense-using-time-cost-tradeoff-analysis -description: >- - Scope defense using time-cost tradeoff analysis. Use when the user needs a product workflow - for project management related to scope defense using time-cost tradeoff analysis. Trigger - terms: scope-management, prioritization, product-design, stakeholder-management. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Scope defense using time-cost tradeoff analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `scope-defense-using-time-cost-tradeoff-analysis` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Scope defense using time-cost tradeoff analysis delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Scope defense using time-cost tradeoff analysis**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{CURRENT_SCOPE}} -- {{NEW_REQUEST}} -- {{PROJECT_CONSTRAINTS}} -- {{TEAM_CAPACITY}} -- {{EXISTING_PRIORITIES}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Scope defense using time-cost tradeoff analysis. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use `{{CURRENT_SCOPE}}`, `{{NEW_REQUEST}}`, `{{PROJECT_CONSTRAINTS}}`, `{{TEAM_CAPACITY}}`, and `{{EXISTING_PRIORITIES}}` to quantify tradeoffs. -- Provide a full effort breakdown (design/engineering/QA/documentation) plus indirect costs. -- Assess timeline, scope, quality, team health, and stakeholder impacts. -- Evaluate user, business, technical, and strategic value with explicit scoring. -- Present at least the five decision options (add/extend, swap, defer, MVP, reject) and recommend one. -- Provide decision criteria, escalation triggers, assumptions, and next steps. - -FORMAT -Return exactly this structure: - -<scope_tradeoff_analysis> -<request_summary> -## New Request Overview - -**Requested by:** [Person/team/stakeholder] -**Request date:** [When request was made] -**Context:** [Why this is being requested - user feedback, competitive pressure, stakeholder priority, etc.] - -**Description:** -[Clear, concise description of what's being requested] - -**Stated rationale:** -[Why requester believes this is important] - -</request_summary> - -<comprehensive_cost_analysis> -## Effort Breakdown - -### Design Effort - -**Research and Discovery:** [X hours] -- [Specific task 1] -- [Specific task 2] -- [Continue...] - -**Concept and Ideation:** [X hours] -- [Specific task] -- [Continue...] - -**Detailed Design:** [X hours] -- [Specific task] -- [Continue...] - -**Iteration and Refinement:** [X hours] -- [Specific task - design reviews, stakeholder feedback, usability testing] -- [Continue...] - -**Design System Work:** [X hours] -- [Specific task - new components, variants, documentation] -- [Continue...] - -**Handoff and Specification:** [X hours] -- [Specific task - redlines, developer collaboration, design QA] -- [Continue...] - -**Total Design Effort:** [X hours] = [Y days] - -### Engineering Effort - -**Technical Discovery:** [X hours] -- [Specific task - architecture decisions, feasibility assessment, spike work] -- [Continue...] - -**Frontend Implementation:** [X hours] -- [Specific task - UI components, styling, interactions, responsive behavior] -- [Continue...] - -**Backend Implementation:** [X hours] (if applicable) -- [Specific task - API changes, database schema, business logic] -- [Continue...] - -**Integration Work:** [X hours] -- [Specific task - connecting frontend to backend, third-party services, etc.] -- [Continue...] - -**Testing and Quality:** [X hours] -- [Specific task - unit tests, integration tests, cross-browser testing] -- [Continue...] - -**Performance Optimization:** [X hours] -- [Specific task] -- [Continue...] - -**Code Review and Refactoring:** [X hours] -- [Specific task] -- [Continue...] - -**Total Engineering Effort:** [X hours] = [Y days] - -### QA and Validation Effort - -**Test Planning:** [X hours] -- [Specific task] -- [Continue...] - -**Manual Testing:** [X hours] -- [Specific task - functional, cross-browser, responsive, device testing] -- [Continue...] - -**Automated Testing:** [X hours] (if applicable) -- [Specific task] -- [Continue...] - -**Regression Testing:** [X hours] -- [Specific task - ensuring no breakage in existing functionality] -- [Continue...] - -**Accessibility Testing:** [X hours] -- [Specific task - keyboard navigation, screen reader, WCAG compliance] -- [Continue...] - -**Edge Case Testing:** [X hours] -- [Specific task] -- [Continue...] - -**Bug Fixing Cycles:** [X hours] -- [Expected iteration time based on complexity] - -**Total QA Effort:** [X hours] = [Y days] - -### Documentation and Communication - -**User Documentation:** [X hours] -- [Help articles, tooltips, onboarding content] - -**Technical Documentation:** [X hours] -- [Technical specs, API docs, architecture decisions] - -**Stakeholder Communication:** [X hours] -- [Updates, demos, alignment meetings] - -**Team Onboarding:** [X hours] -- [Training team members on new feature] - -**Total Documentation:** [X hours] - -### Total Direct Effort - -**Total Hours:** [Sum of all above] hours -**Total Days:** [Accounting for parallel work] days -**Confidence Level:** [High / Medium / Low] -- [Explanation of confidence - e.g., "Medium confidence - design is straightforward but engineering unknowns exist"] - -## Hidden and Indirect Costs - -**Technical Debt:** -- [Description of shortcuts or compromises this introduces] -- [Future cost to address this debt: X days] -- [Impact on codebase maintainability or complexity] - -**Future Maintenance Burden:** -- [Ongoing cost to support, enhance, and troubleshoot this feature] -- [Estimated: X hours per quarter] - -**Complexity Tax:** -- [How this increases overall product or codebase complexity] -- [Impact on future development speed or onboarding] - -**Opportunity Cost:** -- [What else could be accomplished with this time?] -- [Specific alternatives: e.g., "Could complete [other feature] or [technical improvement]"] - -**Context Switching Cost:** -- [Cost of interrupting current work to accommodate this] -- [Estimated productivity loss: X hours] - -**Risk Additions:** -- [New failure modes introduced: e.g., "Additional error states to handle"] -- [Increased testing surface area] -- [Potential user confusion: e.g., "Adds complexity to already complex flow"] - -**Total Indirect Cost:** [Estimated in hours or qualitative assessment] - -</comprehensive_cost_analysis> - -<impact_assessment> -## Impact on Timeline - -**Current Committed Deadline:** [Date] -**Revised Deadline (if adding this):** [New date] (+X days/weeks) - -**Milestone Slippage:** -- [Milestone 1]: [Original date] โ†’ [New date] -- [Milestone 2]: [Original date] โ†’ [New date] -- [Continue...] - -**Dependencies Affected:** -- [Team/project depending on original timeline] - [Impact] -- [Continue...] - -**Market/Business Timing Concerns:** -- [Product launch window, competitive deadline, seasonal timing, customer commitments, etc.] - -## Impact on Scope (If Timeline Holds) - -**What must be deprioritized or cut to fit this in:** - -**Item 1:** [Feature or work item] -- **Description:** [What this is] -- **Current status:** [In progress, planned, etc.] -- **Value lost:** [User and business impact of cutting this] -- **Effort saved:** [X days] - -**Item 2:** [Feature or work item] -[Same structure] - -[Continue for all items that would need to be cut] - -**Total scope reduction:** [X days saved] (offsetting [Y days] required for new request) - -## Impact on Quality and Risk - -**Testing Coverage:** -- [Impact on test coverage if timeline is constrained] -- [Higher bug risk in: specific areas] - -**Design Quality:** -- [Areas where design would be rushed or less polished] -- [UX debt created: e.g., "Inconsistency with design system," "Less iteration on interaction model"] - -**Technical Quality:** -- [Code shortcuts required to meet deadline] -- [Long-term maintenance issues created] - -**Accessibility:** -- [Risk of cutting accessibility work if time is tight] -- [Compliance and usability impact] - -**User Experience Consistency:** -- [Risk of poor integration with existing features] -- [Design system alignment compromised] - -## Impact on Team Health - -**Morale:** -- [Effect of constant scope changes on team confidence and trust] - -**Burnout Risk:** -- [If timeline doesn't adjust, team must absorb increased work] -- [Current team utilization: X% - adding this increases to Y%] - -**Context Switching:** -- [Cost of disrupting current focused work] -- [Productivity impact] - -**Trust and Commitments:** -- [Impact on team's trust if commitments repeatedly change] - -## Stakeholder and Communication Impact - -**Who needs to be informed:** -- [Leadership, marketing, sales, customers, partners, etc.] - -**External commitments affected:** -- [Press releases, customer promises, partnerships, events, etc.] - -**Credibility impact:** -- [Effect on credibility of missing committed dates] -- [Relationship impact with stakeholders] - -</impact_assessment> - -<value_evaluation> -## User Impact Assessment - -**Affected Users:** -- **Percentage/Number:** [e.g., "30% of active users" or "All new users during onboarding"] -- **Personas:** [Which specific user types benefit] - -**Use Case Frequency:** -- [How often users encounter this scenario] -- Daily / Weekly / Monthly / Rare edge case - -**Severity of Need:** -- [ ] **Blocker:** Users cannot accomplish core task without this -- [ ] **Major friction:** Users can accomplish task but with significant difficulty/inefficiency -- [ ] **Minor improvement:** Nice-to-have that slightly improves experience -- [ ] **Delight feature:** Pure enhancement with no functional necessity - -**User Workarounds:** -- [How users currently achieve this goal (if possible)] -- [Cost/pain of workaround: time, frustration, error rate] - -**User Impact Score:** [X/10] -- **Calculation:** [# users] ร— [frequency] ร— [severity] -- **Rationale:** [Explanation of score] - -## Business Impact Assessment - -**Revenue Impact:** -- [Does this directly affect revenue?] -- **Quantified:** [e.g., "Expected to increase conversion by 5%, worth $200K annually"] -- **Qualitative:** [e.g., "Required for enterprise sales" or "Reduces churn risk"] - -**Cost Savings:** -- [Does this reduce operational costs, support burden, technical debt?] -- [Quantified if possible] - -**Strategic Alignment:** -- [ ] **High:** Core to strategic direction, unlocks future initiatives -- [ ] **Medium:** Supports strategy but not critical path -- [ ] **Low:** Tangential or unrelated to strategic priorities -- **Explanation:** [How this fits or doesn't fit strategy] - -**Competitive Necessity:** -- [ ] **Must-have:** Competitors all have this, we're behind without it -- [ ] **Nice-to-have:** Would match competitors but not falling behind without it -- [ ] **Differentiator:** Opportunity to exceed competitors and stand out -- **Explanation:** [Competitive landscape context] - -**Market Timing:** -- [Does this need to launch with initial release?] -- [Reason: competitive window, customer commitment, seasonal timing, etc.] - -**Business Impact Score:** [X/10] -- **Rationale:** [Explanation based on revenue + strategy + competitive factors] - -## Technical and Strategic Impact - -**Enables Future Work:** -- [Does this create foundation for future features?] -- [Specific examples of what this unlocks] - -**Reduces Technical Debt:** -- [Does this pay down existing debt or prevent future debt?] - -**Platform Investment:** -- [Does this strengthen platform/design system for long-term benefit?] - -**Learning Value:** -- [Does this teach us something important about users or technology?] -- [Validation or de-risking value] - -## Relative Value Comparison - -**Value of New Request:** [User impact score + Business impact score] = [Total] - -**Value of Work That Would Be Delayed/Cut:** -- **Item 1:** [Name] - [User impact X/10 + Business impact Y/10] = [Total] -- **Item 2:** [Name] - [User impact X/10 + Business impact Y/10] = [Total] -- [Continue...] - -**Comparison:** -[Is new request higher or lower value than what it would replace?] - -**Opportunity Cost Analysis:** -[What else could be accomplished with same effort - specific alternatives and their value] - -**Value Ranking:** -1. [Highest value item] -2. [Second highest] -3. [Continue...] - -**Conclusion:** [Is new request top priority compared to alternatives?] - -</value_evaluation> - -<decision_options> -## Option 1: Add to Scope with Timeline Extension - -**Description:** Include new request, extend deadline to accommodate full effort - -**Timeline Change:** -- **Original deadline:** [Date] -- **New deadline:** [Date] (+X days/weeks) - -**Cost:** -- **Delayed launch:** [Business impact - e.g., "Miss Q4 launch window"] -- **Missed market timing:** [If applicable - competitive announcement, seasonal timing] -- **Stakeholder impact:** [Who this affects and how] -- **Team impact:** [Extended project, potential fatigue] - -**Benefit:** -- Full scope delivered with quality -- No compromises to existing commitments -- Team has adequate time for quality work -- All value realized: [New request + existing scope] - -**Tradeoff Summary:** More complete product, later delivery - -**When to Choose:** Market timing is flexible and complete feature set is more important than launch date - -**Risks:** -- [Market window may close] -- [Competitor may launch first] -- [Team morale if project extends too long] - -## Option 2: Swap for Existing Scope (Maintain Timeline) - -**Description:** Include new request, cut other work to maintain timeline - -**What Gets Cut:** - -**Cut Item 1:** [Name] -- **Description:** [What this is] -- **Value lost:** [User impact X/10, Business impact Y/10] -- **Justification for cut:** [Why this is lower priority than new request] -- **Effort saved:** [X days] - -**Cut Item 2:** [Name] -[Same structure] - -[Continue...] - -**Cost:** -- Lost value from cut items: [Total value score] -- Potential technical debt: [If cutting quality work] -- Future rework: [If cut items need revisiting later] - -**Benefit:** -- Maintain original timeline -- Deliver new request at launch -- Value of new request realized: [Score] - -**Tradeoff Summary:** Different scope, same timeline - -**When to Choose:** New request is higher value than what would be cut, and timeline is immovable - -**Risks:** -- [Value judgment may be wrong - cut item may prove more important] -- [User confusion if expected features are missing] - -## Option 3: Defer to Next Phase/Release - -**Description:** Maintain current scope and timeline, add new request to future backlog - -**Next Opportunity:** [When this could be addressed - e.g., "Q2 2025 release"] - -**Cost:** -- Short-term: Users don't benefit from new request at launch -- Temporary workaround: [How users handle gap until next release] -- Potential competitive gap: [If this is competitive feature] - -**Benefit:** -- Maintain scope, timeline, quality of current release -- Team delivers committed work excellently -- Validate need post-launch: [Can gather user feedback first] -- Time to implement properly: [More thoughtful with v1 learnings] - -**Tradeoff Summary:** Launch on time with committed scope, add later - -**When to Choose:** Current scope is sufficient for launch and new request can wait for v2 - -**Risks:** -- [Users may complain about missing feature] -- [Competitive gap if feature is table stakes] - -## Option 4: Deliver Simplified/MVP Version - -**Description:** Include reduced version delivering core value with less effort - -**Simplified Scope:** -- **Included:** [Core functionality in MVP] -- **Deferred:** [Advanced features, edge cases, polish saved for v2] - -**Effort Comparison:** -- **Original estimate:** [X days] -- **Simplified version:** [Y days] -- **Savings:** [Z days] - -**Cost:** -- Reduced functionality: [What users don't get] -- Future enhancement needed: [Likely to revisit] -- Potential user confusion: [If simplified version has limitations] - -**Benefit:** -- Partial value realized now -- Lower cost and risk -- Validate before full investment -- Enhance in future based on usage - -**Tradeoff Summary:** Some value now, full value later - -**When to Choose:** Core value can be delivered simply and full version can wait for validation - -**Risks:** -- [Users may be confused by limitations] -- [May create technical debt if MVP not architected for future expansion] - -## Option 5: Reject (Maintain Current Plan) - -**Description:** Do not include new request in current project - -**Cost:** -- Value of request not realized -- Requester may be disappointed -- Potential missed opportunity - -**Benefit:** -- Team maintains focus -- Delivers committed work with quality -- Preserves timeline and stakeholder commitments - -**Tradeoff Summary:** Focused delivery of original scope - -**When to Choose:** New request is significantly lower value than committed work and can be addressed separately (or not at all) - -**Risks:** -- [Requester pushback] -- [May have been right that this was important] - -</decision_options> - -<recommendation> -## Recommended Approach - -**Selected Option:** [Option number and name] - -**Rationale:** - -**Value Analysis:** -- [How value of new request compares to alternatives] -- [Whether value justifies cost and tradeoffs] - -**Cost-Benefit:** -- [Effort required: X days] -- [Value delivered: Y score] -- [Comparison to alternatives] - -**Strategic Fit:** -- [Alignment with company/product goals and priorities] -- [Long-term vs. short-term considerations] - -**Risk Assessment:** -- [Key risks identified] -- [How chosen option mitigates or accepts risks] - -**Key Deciding Factors:** -1. **[Factor 1]:** [e.g., "Market timing is critical - launch date cannot slip"] -2. **[Factor 2]:** [e.g., "New request has 8/10 user impact vs. cut item with 4/10"] -3. **[Factor 3]:** [e.g., "Simplified version delivers 80% value for 30% effort"] - -**Confidence Level:** [High / Medium / Low] -- **Explanation:** [Why this confidence level - known vs. unknown factors] - -**Alternative if Context Changes:** -- **If [assumption/constraint changes]:** [Consider alternative option] -- **Example:** "If launch deadline extends by 3 weeks, reconsider Option 1 (full scope with timeline extension)" - -</recommendation> - -<decision_framework> -## Questions to Guide Decision - -**Must-Have Test:** -- Is this absolutely required for product to be useful/sellable at launch? -- Why or why not? -- What's the minimum viable version needed? - -**User Workaround Assessment:** -- Can users accomplish their goal without this feature? -- What's the cost of that workaround (time, frustration, errors)? -- Is the workaround acceptable short-term? - -**Delay Cost Analysis:** -- What happens if we launch without this and add it in next release? -- Do we lose customers, revenue, or competitive position? -- Or is delay impact minimal? - -**Value Comparison:** -- Is this higher priority than what it would delay or replace? -- Run the value scores side-by-side -- What do users and business need most? - -**Risk Tolerance:** -- Are we willing to accept quality/timeline tradeoffs to include this? -- What risks are acceptable vs. unacceptable? -- What's our risk appetite right now? - -**Strategic Lens:** -- Does this advance our strategic vision and differentiation? -- Or is this a distraction from core value proposition? - -## Decision Criteria - -**Inclusion threshold:** -- If [User impact score ร— Business impact score] โ‰ฅ [Threshold - e.g., 50], strongly consider including -- If below threshold, likely defer or reject - -**Capacity check:** -- If [Effort estimate] > [Available capacity buffer], timeline MUST extend or scope MUST swap -- If within buffer, can potentially absorb - -**Timeline constraint:** -- If [Timeline delay] > [Acceptable window - e.g., 2 weeks], must cut other scope or reject -- If within acceptable delay, timeline extension is option - -**Authority escalation:** -- If requester is [C-level or VP], escalate to [decision maker at same level] -- Ensure tradeoffs are visible to appropriate decision-making level - -## Escalation Triggers - -**Escalate to [Leadership Level] if:** -- Timeline impact exceeds [X weeks] -- Scope change affects previously communicated external commitments (customer, press, partnerships) -- Multiple senior stakeholders disagree on priority -- Request comes from executive leadership (requires executive tradeoff discussion) -- Team flags significant technical risk, debt, or feasibility concerns - -**Decision Owner:** [Role - PM, Design Lead, Director, VP, etc.] - -**Decision Timeline:** Decision must be made by [Date] to avoid impacting project critical path - -</decision_framework> - -<assumptions_and_next_steps> -## Key Assumptions - -**Assumption 1:** [e.g., "Effort estimate assumes no major technical blockers"] -- **Validation needed:** [Engineering spike or deeper technical review] -- **If wrong:** [Impact on recommendation] - -**Assumption 2:** [e.g., "User impact score based on current usage patterns"] -- **Validation needed:** [User research or analytics review] -- **If wrong:** [Impact on recommendation] - -**Assumption 3:** [e.g., "Timeline extension assumes no dependencies on other teams"] -- **Validation needed:** [Confirm with dependent teams] -- **If wrong:** [Impact on recommendation] - -[Continue for all key assumptions] - -## Validation Needed - -**Before final decision:** -- [ ] Engineering review of effort estimate for technical accuracy -- [ ] Stakeholder confirmation of whether timeline can extend (if considering Option 1) -- [ ] Product/business review of value assessment -- [ ] Team capacity check for bandwidth to absorb (if considering Option 2 or 4) - -## Next Steps - -**Immediate:** -1. Share this analysis with decision maker and key stakeholders -2. Schedule decision meeting by [Date] -3. Gather validation inputs listed above - -**Post-Decision:** - -**If approved (Option 1, 2, or 4):** -- Update project plan with new scope -- Adjust milestones and timeline -- Communicate changes to team and affected stakeholders -- Update external commitments (if timeline changed) -- Reprioritize backlog (if scope swapped) - -**If deferred (Option 3):** -- Add to backlog with full context from this analysis -- Set review date for next planning cycle [Date] -- Communicate decision and rationale to requester -- Document why deferred for future reference - -**If rejected (Option 5):** -- Document decision and rationale -- Communicate thoughtfully to requester (explain tradeoffs, not just "no") -- Note for future: if this request returns, reference this analysis - -**Communication Plan:** -- [Who to inform of decision] -- [What to communicate (decision, rationale, timeline impact)] -- [When to communicate (immediately post-decision)] - -</assumptions_and_next_steps> -</scope_tradeoff_analysis> - -FAILURE -- Any required section in `<scope_tradeoff_analysis>` is missing or materially incomplete. -- Cost breakdown, impact assessment, or value evaluation is missing or superficial. -- Recommendation lacks clear rationale or does not reference tradeoff options. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/scope-defense-using-time-cost-tradeoff-analysis/SKILL.md.tmpl b/skills/scope-defense-using-time-cost-tradeoff-analysis/SKILL.md.tmpl deleted file mode 100644 index ca23f3cc..00000000 --- a/skills/scope-defense-using-time-cost-tradeoff-analysis/SKILL.md.tmpl +++ /dev/null @@ -1,716 +0,0 @@ ---- -name: scope-defense-using-time-cost-tradeoff-analysis -description: >- - Scope defense using time-cost tradeoff analysis. Use when the user needs a product workflow - for project management related to scope defense using time-cost tradeoff analysis. Trigger - terms: scope-management, prioritization, product-design, stakeholder-management. ---- -# Scope defense using time-cost tradeoff analysis - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Scope defense using time-cost tradeoff analysis**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{CURRENT_SCOPE}} -- {{NEW_REQUEST}} -- {{PROJECT_CONSTRAINTS}} -- {{TEAM_CAPACITY}} -- {{EXISTING_PRIORITIES}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Scope defense using time-cost tradeoff analysis. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Use `{{CURRENT_SCOPE}}`, `{{NEW_REQUEST}}`, `{{PROJECT_CONSTRAINTS}}`, `{{TEAM_CAPACITY}}`, and `{{EXISTING_PRIORITIES}}` to quantify tradeoffs. -- Provide a full effort breakdown (design/engineering/QA/documentation) plus indirect costs. -- Assess timeline, scope, quality, team health, and stakeholder impacts. -- Evaluate user, business, technical, and strategic value with explicit scoring. -- Present at least the five decision options (add/extend, swap, defer, MVP, reject) and recommend one. -- Provide decision criteria, escalation triggers, assumptions, and next steps. - -FORMAT -Return exactly this structure: - -<scope_tradeoff_analysis> -<request_summary> -## New Request Overview - -**Requested by:** [Person/team/stakeholder] -**Request date:** [When request was made] -**Context:** [Why this is being requested - user feedback, competitive pressure, stakeholder priority, etc.] - -**Description:** -[Clear, concise description of what's being requested] - -**Stated rationale:** -[Why requester believes this is important] - -</request_summary> - -<comprehensive_cost_analysis> -## Effort Breakdown - -### Design Effort - -**Research and Discovery:** [X hours] -- [Specific task 1] -- [Specific task 2] -- [Continue...] - -**Concept and Ideation:** [X hours] -- [Specific task] -- [Continue...] - -**Detailed Design:** [X hours] -- [Specific task] -- [Continue...] - -**Iteration and Refinement:** [X hours] -- [Specific task - design reviews, stakeholder feedback, usability testing] -- [Continue...] - -**Design System Work:** [X hours] -- [Specific task - new components, variants, documentation] -- [Continue...] - -**Handoff and Specification:** [X hours] -- [Specific task - redlines, developer collaboration, design QA] -- [Continue...] - -**Total Design Effort:** [X hours] = [Y days] - -### Engineering Effort - -**Technical Discovery:** [X hours] -- [Specific task - architecture decisions, feasibility assessment, spike work] -- [Continue...] - -**Frontend Implementation:** [X hours] -- [Specific task - UI components, styling, interactions, responsive behavior] -- [Continue...] - -**Backend Implementation:** [X hours] (if applicable) -- [Specific task - API changes, database schema, business logic] -- [Continue...] - -**Integration Work:** [X hours] -- [Specific task - connecting frontend to backend, third-party services, etc.] -- [Continue...] - -**Testing and Quality:** [X hours] -- [Specific task - unit tests, integration tests, cross-browser testing] -- [Continue...] - -**Performance Optimization:** [X hours] -- [Specific task] -- [Continue...] - -**Code Review and Refactoring:** [X hours] -- [Specific task] -- [Continue...] - -**Total Engineering Effort:** [X hours] = [Y days] - -### QA and Validation Effort - -**Test Planning:** [X hours] -- [Specific task] -- [Continue...] - -**Manual Testing:** [X hours] -- [Specific task - functional, cross-browser, responsive, device testing] -- [Continue...] - -**Automated Testing:** [X hours] (if applicable) -- [Specific task] -- [Continue...] - -**Regression Testing:** [X hours] -- [Specific task - ensuring no breakage in existing functionality] -- [Continue...] - -**Accessibility Testing:** [X hours] -- [Specific task - keyboard navigation, screen reader, WCAG compliance] -- [Continue...] - -**Edge Case Testing:** [X hours] -- [Specific task] -- [Continue...] - -**Bug Fixing Cycles:** [X hours] -- [Expected iteration time based on complexity] - -**Total QA Effort:** [X hours] = [Y days] - -### Documentation and Communication - -**User Documentation:** [X hours] -- [Help articles, tooltips, onboarding content] - -**Technical Documentation:** [X hours] -- [Technical specs, API docs, architecture decisions] - -**Stakeholder Communication:** [X hours] -- [Updates, demos, alignment meetings] - -**Team Onboarding:** [X hours] -- [Training team members on new feature] - -**Total Documentation:** [X hours] - -### Total Direct Effort - -**Total Hours:** [Sum of all above] hours -**Total Days:** [Accounting for parallel work] days -**Confidence Level:** [High / Medium / Low] -- [Explanation of confidence - e.g., "Medium confidence - design is straightforward but engineering unknowns exist"] - -## Hidden and Indirect Costs - -**Technical Debt:** -- [Description of shortcuts or compromises this introduces] -- [Future cost to address this debt: X days] -- [Impact on codebase maintainability or complexity] - -**Future Maintenance Burden:** -- [Ongoing cost to support, enhance, and troubleshoot this feature] -- [Estimated: X hours per quarter] - -**Complexity Tax:** -- [How this increases overall product or codebase complexity] -- [Impact on future development speed or onboarding] - -**Opportunity Cost:** -- [What else could be accomplished with this time?] -- [Specific alternatives: e.g., "Could complete [other feature] or [technical improvement]"] - -**Context Switching Cost:** -- [Cost of interrupting current work to accommodate this] -- [Estimated productivity loss: X hours] - -**Risk Additions:** -- [New failure modes introduced: e.g., "Additional error states to handle"] -- [Increased testing surface area] -- [Potential user confusion: e.g., "Adds complexity to already complex flow"] - -**Total Indirect Cost:** [Estimated in hours or qualitative assessment] - -</comprehensive_cost_analysis> - -<impact_assessment> -## Impact on Timeline - -**Current Committed Deadline:** [Date] -**Revised Deadline (if adding this):** [New date] (+X days/weeks) - -**Milestone Slippage:** -- [Milestone 1]: [Original date] โ†’ [New date] -- [Milestone 2]: [Original date] โ†’ [New date] -- [Continue...] - -**Dependencies Affected:** -- [Team/project depending on original timeline] - [Impact] -- [Continue...] - -**Market/Business Timing Concerns:** -- [Product launch window, competitive deadline, seasonal timing, customer commitments, etc.] - -## Impact on Scope (If Timeline Holds) - -**What must be deprioritized or cut to fit this in:** - -**Item 1:** [Feature or work item] -- **Description:** [What this is] -- **Current status:** [In progress, planned, etc.] -- **Value lost:** [User and business impact of cutting this] -- **Effort saved:** [X days] - -**Item 2:** [Feature or work item] -[Same structure] - -[Continue for all items that would need to be cut] - -**Total scope reduction:** [X days saved] (offsetting [Y days] required for new request) - -## Impact on Quality and Risk - -**Testing Coverage:** -- [Impact on test coverage if timeline is constrained] -- [Higher bug risk in: specific areas] - -**Design Quality:** -- [Areas where design would be rushed or less polished] -- [UX debt created: e.g., "Inconsistency with design system," "Less iteration on interaction model"] - -**Technical Quality:** -- [Code shortcuts required to meet deadline] -- [Long-term maintenance issues created] - -**Accessibility:** -- [Risk of cutting accessibility work if time is tight] -- [Compliance and usability impact] - -**User Experience Consistency:** -- [Risk of poor integration with existing features] -- [Design system alignment compromised] - -## Impact on Team Health - -**Morale:** -- [Effect of constant scope changes on team confidence and trust] - -**Burnout Risk:** -- [If timeline doesn't adjust, team must absorb increased work] -- [Current team utilization: X% - adding this increases to Y%] - -**Context Switching:** -- [Cost of disrupting current focused work] -- [Productivity impact] - -**Trust and Commitments:** -- [Impact on team's trust if commitments repeatedly change] - -## Stakeholder and Communication Impact - -**Who needs to be informed:** -- [Leadership, marketing, sales, customers, partners, etc.] - -**External commitments affected:** -- [Press releases, customer promises, partnerships, events, etc.] - -**Credibility impact:** -- [Effect on credibility of missing committed dates] -- [Relationship impact with stakeholders] - -</impact_assessment> - -<value_evaluation> -## User Impact Assessment - -**Affected Users:** -- **Percentage/Number:** [e.g., "30% of active users" or "All new users during onboarding"] -- **Personas:** [Which specific user types benefit] - -**Use Case Frequency:** -- [How often users encounter this scenario] -- Daily / Weekly / Monthly / Rare edge case - -**Severity of Need:** -- [ ] **Blocker:** Users cannot accomplish core task without this -- [ ] **Major friction:** Users can accomplish task but with significant difficulty/inefficiency -- [ ] **Minor improvement:** Nice-to-have that slightly improves experience -- [ ] **Delight feature:** Pure enhancement with no functional necessity - -**User Workarounds:** -- [How users currently achieve this goal (if possible)] -- [Cost/pain of workaround: time, frustration, error rate] - -**User Impact Score:** [X/10] -- **Calculation:** [# users] ร— [frequency] ร— [severity] -- **Rationale:** [Explanation of score] - -## Business Impact Assessment - -**Revenue Impact:** -- [Does this directly affect revenue?] -- **Quantified:** [e.g., "Expected to increase conversion by 5%, worth $200K annually"] -- **Qualitative:** [e.g., "Required for enterprise sales" or "Reduces churn risk"] - -**Cost Savings:** -- [Does this reduce operational costs, support burden, technical debt?] -- [Quantified if possible] - -**Strategic Alignment:** -- [ ] **High:** Core to strategic direction, unlocks future initiatives -- [ ] **Medium:** Supports strategy but not critical path -- [ ] **Low:** Tangential or unrelated to strategic priorities -- **Explanation:** [How this fits or doesn't fit strategy] - -**Competitive Necessity:** -- [ ] **Must-have:** Competitors all have this, we're behind without it -- [ ] **Nice-to-have:** Would match competitors but not falling behind without it -- [ ] **Differentiator:** Opportunity to exceed competitors and stand out -- **Explanation:** [Competitive landscape context] - -**Market Timing:** -- [Does this need to launch with initial release?] -- [Reason: competitive window, customer commitment, seasonal timing, etc.] - -**Business Impact Score:** [X/10] -- **Rationale:** [Explanation based on revenue + strategy + competitive factors] - -## Technical and Strategic Impact - -**Enables Future Work:** -- [Does this create foundation for future features?] -- [Specific examples of what this unlocks] - -**Reduces Technical Debt:** -- [Does this pay down existing debt or prevent future debt?] - -**Platform Investment:** -- [Does this strengthen platform/design system for long-term benefit?] - -**Learning Value:** -- [Does this teach us something important about users or technology?] -- [Validation or de-risking value] - -## Relative Value Comparison - -**Value of New Request:** [User impact score + Business impact score] = [Total] - -**Value of Work That Would Be Delayed/Cut:** -- **Item 1:** [Name] - [User impact X/10 + Business impact Y/10] = [Total] -- **Item 2:** [Name] - [User impact X/10 + Business impact Y/10] = [Total] -- [Continue...] - -**Comparison:** -[Is new request higher or lower value than what it would replace?] - -**Opportunity Cost Analysis:** -[What else could be accomplished with same effort - specific alternatives and their value] - -**Value Ranking:** -1. [Highest value item] -2. [Second highest] -3. [Continue...] - -**Conclusion:** [Is new request top priority compared to alternatives?] - -</value_evaluation> - -<decision_options> -## Option 1: Add to Scope with Timeline Extension - -**Description:** Include new request, extend deadline to accommodate full effort - -**Timeline Change:** -- **Original deadline:** [Date] -- **New deadline:** [Date] (+X days/weeks) - -**Cost:** -- **Delayed launch:** [Business impact - e.g., "Miss Q4 launch window"] -- **Missed market timing:** [If applicable - competitive announcement, seasonal timing] -- **Stakeholder impact:** [Who this affects and how] -- **Team impact:** [Extended project, potential fatigue] - -**Benefit:** -- Full scope delivered with quality -- No compromises to existing commitments -- Team has adequate time for quality work -- All value realized: [New request + existing scope] - -**Tradeoff Summary:** More complete product, later delivery - -**When to Choose:** Market timing is flexible and complete feature set is more important than launch date - -**Risks:** -- [Market window may close] -- [Competitor may launch first] -- [Team morale if project extends too long] - -## Option 2: Swap for Existing Scope (Maintain Timeline) - -**Description:** Include new request, cut other work to maintain timeline - -**What Gets Cut:** - -**Cut Item 1:** [Name] -- **Description:** [What this is] -- **Value lost:** [User impact X/10, Business impact Y/10] -- **Justification for cut:** [Why this is lower priority than new request] -- **Effort saved:** [X days] - -**Cut Item 2:** [Name] -[Same structure] - -[Continue...] - -**Cost:** -- Lost value from cut items: [Total value score] -- Potential technical debt: [If cutting quality work] -- Future rework: [If cut items need revisiting later] - -**Benefit:** -- Maintain original timeline -- Deliver new request at launch -- Value of new request realized: [Score] - -**Tradeoff Summary:** Different scope, same timeline - -**When to Choose:** New request is higher value than what would be cut, and timeline is immovable - -**Risks:** -- [Value judgment may be wrong - cut item may prove more important] -- [User confusion if expected features are missing] - -## Option 3: Defer to Next Phase/Release - -**Description:** Maintain current scope and timeline, add new request to future backlog - -**Next Opportunity:** [When this could be addressed - e.g., "Q2 2025 release"] - -**Cost:** -- Short-term: Users don't benefit from new request at launch -- Temporary workaround: [How users handle gap until next release] -- Potential competitive gap: [If this is competitive feature] - -**Benefit:** -- Maintain scope, timeline, quality of current release -- Team delivers committed work excellently -- Validate need post-launch: [Can gather user feedback first] -- Time to implement properly: [More thoughtful with v1 learnings] - -**Tradeoff Summary:** Launch on time with committed scope, add later - -**When to Choose:** Current scope is sufficient for launch and new request can wait for v2 - -**Risks:** -- [Users may complain about missing feature] -- [Competitive gap if feature is table stakes] - -## Option 4: Deliver Simplified/MVP Version - -**Description:** Include reduced version delivering core value with less effort - -**Simplified Scope:** -- **Included:** [Core functionality in MVP] -- **Deferred:** [Advanced features, edge cases, polish saved for v2] - -**Effort Comparison:** -- **Original estimate:** [X days] -- **Simplified version:** [Y days] -- **Savings:** [Z days] - -**Cost:** -- Reduced functionality: [What users don't get] -- Future enhancement needed: [Likely to revisit] -- Potential user confusion: [If simplified version has limitations] - -**Benefit:** -- Partial value realized now -- Lower cost and risk -- Validate before full investment -- Enhance in future based on usage - -**Tradeoff Summary:** Some value now, full value later - -**When to Choose:** Core value can be delivered simply and full version can wait for validation - -**Risks:** -- [Users may be confused by limitations] -- [May create technical debt if MVP not architected for future expansion] - -## Option 5: Reject (Maintain Current Plan) - -**Description:** Do not include new request in current project - -**Cost:** -- Value of request not realized -- Requester may be disappointed -- Potential missed opportunity - -**Benefit:** -- Team maintains focus -- Delivers committed work with quality -- Preserves timeline and stakeholder commitments - -**Tradeoff Summary:** Focused delivery of original scope - -**When to Choose:** New request is significantly lower value than committed work and can be addressed separately (or not at all) - -**Risks:** -- [Requester pushback] -- [May have been right that this was important] - -</decision_options> - -<recommendation> -## Recommended Approach - -**Selected Option:** [Option number and name] - -**Rationale:** - -**Value Analysis:** -- [How value of new request compares to alternatives] -- [Whether value justifies cost and tradeoffs] - -**Cost-Benefit:** -- [Effort required: X days] -- [Value delivered: Y score] -- [Comparison to alternatives] - -**Strategic Fit:** -- [Alignment with company/product goals and priorities] -- [Long-term vs. short-term considerations] - -**Risk Assessment:** -- [Key risks identified] -- [How chosen option mitigates or accepts risks] - -**Key Deciding Factors:** -1. **[Factor 1]:** [e.g., "Market timing is critical - launch date cannot slip"] -2. **[Factor 2]:** [e.g., "New request has 8/10 user impact vs. cut item with 4/10"] -3. **[Factor 3]:** [e.g., "Simplified version delivers 80% value for 30% effort"] - -**Confidence Level:** [High / Medium / Low] -- **Explanation:** [Why this confidence level - known vs. unknown factors] - -**Alternative if Context Changes:** -- **If [assumption/constraint changes]:** [Consider alternative option] -- **Example:** "If launch deadline extends by 3 weeks, reconsider Option 1 (full scope with timeline extension)" - -</recommendation> - -<decision_framework> -## Questions to Guide Decision - -**Must-Have Test:** -- Is this absolutely required for product to be useful/sellable at launch? -- Why or why not? -- What's the minimum viable version needed? - -**User Workaround Assessment:** -- Can users accomplish their goal without this feature? -- What's the cost of that workaround (time, frustration, errors)? -- Is the workaround acceptable short-term? - -**Delay Cost Analysis:** -- What happens if we launch without this and add it in next release? -- Do we lose customers, revenue, or competitive position? -- Or is delay impact minimal? - -**Value Comparison:** -- Is this higher priority than what it would delay or replace? -- Run the value scores side-by-side -- What do users and business need most? - -**Risk Tolerance:** -- Are we willing to accept quality/timeline tradeoffs to include this? -- What risks are acceptable vs. unacceptable? -- What's our risk appetite right now? - -**Strategic Lens:** -- Does this advance our strategic vision and differentiation? -- Or is this a distraction from core value proposition? - -## Decision Criteria - -**Inclusion threshold:** -- If [User impact score ร— Business impact score] โ‰ฅ [Threshold - e.g., 50], strongly consider including -- If below threshold, likely defer or reject - -**Capacity check:** -- If [Effort estimate] > [Available capacity buffer], timeline MUST extend or scope MUST swap -- If within buffer, can potentially absorb - -**Timeline constraint:** -- If [Timeline delay] > [Acceptable window - e.g., 2 weeks], must cut other scope or reject -- If within acceptable delay, timeline extension is option - -**Authority escalation:** -- If requester is [C-level or VP], escalate to [decision maker at same level] -- Ensure tradeoffs are visible to appropriate decision-making level - -## Escalation Triggers - -**Escalate to [Leadership Level] if:** -- Timeline impact exceeds [X weeks] -- Scope change affects previously communicated external commitments (customer, press, partnerships) -- Multiple senior stakeholders disagree on priority -- Request comes from executive leadership (requires executive tradeoff discussion) -- Team flags significant technical risk, debt, or feasibility concerns - -**Decision Owner:** [Role - PM, Design Lead, Director, VP, etc.] - -**Decision Timeline:** Decision must be made by [Date] to avoid impacting project critical path - -</decision_framework> - -<assumptions_and_next_steps> -## Key Assumptions - -**Assumption 1:** [e.g., "Effort estimate assumes no major technical blockers"] -- **Validation needed:** [Engineering spike or deeper technical review] -- **If wrong:** [Impact on recommendation] - -**Assumption 2:** [e.g., "User impact score based on current usage patterns"] -- **Validation needed:** [User research or analytics review] -- **If wrong:** [Impact on recommendation] - -**Assumption 3:** [e.g., "Timeline extension assumes no dependencies on other teams"] -- **Validation needed:** [Confirm with dependent teams] -- **If wrong:** [Impact on recommendation] - -[Continue for all key assumptions] - -## Validation Needed - -**Before final decision:** -- [ ] Engineering review of effort estimate for technical accuracy -- [ ] Stakeholder confirmation of whether timeline can extend (if considering Option 1) -- [ ] Product/business review of value assessment -- [ ] Team capacity check for bandwidth to absorb (if considering Option 2 or 4) - -## Next Steps - -**Immediate:** -1. Share this analysis with decision maker and key stakeholders -2. Schedule decision meeting by [Date] -3. Gather validation inputs listed above - -**Post-Decision:** - -**If approved (Option 1, 2, or 4):** -- Update project plan with new scope -- Adjust milestones and timeline -- Communicate changes to team and affected stakeholders -- Update external commitments (if timeline changed) -- Reprioritize backlog (if scope swapped) - -**If deferred (Option 3):** -- Add to backlog with full context from this analysis -- Set review date for next planning cycle [Date] -- Communicate decision and rationale to requester -- Document why deferred for future reference - -**If rejected (Option 5):** -- Document decision and rationale -- Communicate thoughtfully to requester (explain tradeoffs, not just "no") -- Note for future: if this request returns, reference this analysis - -**Communication Plan:** -- [Who to inform of decision] -- [What to communicate (decision, rationale, timeline impact)] -- [When to communicate (immediately post-decision)] - -</assumptions_and_next_steps> -</scope_tradeoff_analysis> - -FAILURE -- Any required section in `<scope_tradeoff_analysis>` is missing or materially incomplete. -- Cost breakdown, impact assessment, or value evaluation is missing or superficial. -- Recommendation lacks clear rationale or does not reference tradeoff options. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/scope-defense-using-time-cost-tradeoff-analysis/agents/openai.yaml b/skills/scope-defense-using-time-cost-tradeoff-analysis/agents/openai.yaml deleted file mode 100644 index 4882e6e4..00000000 --- a/skills/scope-defense-using-time-cost-tradeoff-analysis/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Scope defense using time-cost tradeoff analysis" - short_description: "Scope defense using time-cost tradeoff analysis. Use when the user needs a product workflow for project management..." - brand_color: "#4F46E5" - default_prompt: "Use $scope-defense-using-time-cost-tradeoff-analysis with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/scope-defense-using-time-cost-tradeoff-analysis/productize.json b/skills/scope-defense-using-time-cost-tradeoff-analysis/productize.json deleted file mode 100644 index 350bd677..00000000 --- a/skills/scope-defense-using-time-cost-tradeoff-analysis/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Scope defense using time-cost tradeoff analysis", - "category": "Delivery", - "lifecycle": "Plan", - "tags": [ - "scope-defense-using-time-cost-tradeoff-analysis", - "scope", - "defense", - "time", - "cost", - "tradeoff" - ], - "use_when": "Scope defense using time-cost tradeoff analysis. Use when the user needs a product workflow for project management related to scope defense using time-cost tradeoff analysis. Trigger terms: scope-management, prioritization, product-design, stakeholder-management.", - "do_not_use_when": "Do not use Scope defense using time-cost tradeoff analysis when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Scope defense using time-cost tradeoff analysis delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "scope-defense-using-time-cost-tradeoff-analysis", - "scope", - "defense", - "time", - "cost", - "tradeoff" - ], - "framework_fit": "Scope defense using time-cost tradeoff analysis fits Delivery work in the Plan lifecycle when the user needs Scope defense using time-cost tradeoff analysis delivery brief with scope, requirements, priorities, risks, and acceptance criteria and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Scope defense using time-cost tradeoff analysis delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Scope defense using time-cost tradeoff analysis as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Scope defense using time-cost tradeoff analysis when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $scope-defense-using-time-cost-tradeoff-analysis to turn this scope context into a decision-ready Scope defense using time-cost tradeoff analysis delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Scope defense using time-cost tradeoff analysis delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md b/skills/sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md deleted file mode 100644 index 88a73927..00000000 --- a/skills/sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: sketch-descriptions-for-wireframes-from-product-ideas -description: >- - Sketch descriptions for wireframes from product ideas. Use when the user needs a product - workflow for design & prototyping related to sketch descriptions for wireframes from product - ideas. Trigger terms: pm, ux, flows, design, prototyping, wireframes. ---- -<!-- AUTO-GENERATED from SKILL.md.tmpl - do not edit directly --> -<!-- Regenerate: npm run skills:generate --> - -# Sketch descriptions for wireframes from product ideas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: <one question> Why it matters: <decision it changes>`. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start "<user request>"` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id <id> --status completed|blocked|deferred|needs-review --artifact-type <type> --summary <summary>` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `sketch-descriptions-for-wireframes-from-product-ideas` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Sketch descriptions for wireframes from product ideas UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Sketch descriptions for wireframes from product ideas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS -<provided_inputs> -- {{PRODUCT_IDEA}} -- {{ADDITIONAL_DETAILS}} -</provided_inputs> - -GOAL -Produce a high-quality deliverable for: Sketch descriptions for wireframes from product ideas. -Success metric: -- Produces 3-5 detailed sketch descriptions covering distinct product flows/aspects. -- Each sketch includes layout, interaction flow, friction reduction, and design variations. -- Output is specific enough for a visual designer to create wireframes/mockups directly. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_IDEA}}` and `{{ADDITIONAL_DETAILS}}`; if details are missing, state assumptions explicitly. -- Generate 3-5 sketches, each focused on a distinct flow/aspect (not minor variants of the same screen). -- For each sketch include: - - Title/identifier - - What the sketch represents - - Key UI elements and placement - - User flow and interaction points - - At least one meaningful variation/alternative -- Incorporate user-centric design, friction reduction, onboarding considerations, consistency, and scalability. -- Do not restate input prompts verbatim in the output. - -FORMAT -Return exactly this structure: - -<sketch_descriptions> -<sketch> -<title>[Sketch title] -[What this sketch represents] -[Key elements and placement] -[Start point -> key actions -> completion point] -[How this sketch reduces friction/pain points] -[Alternative design directions or variants] - -[Repeat `` for each sketch; total 3-5 sketches] - - -FAILURE -- Root tag `` or child `` sections are missing, malformed, or incomplete. -- Fewer than 3 or more than 5 sketches are provided. -- Any sketch is missing one or more required fields from `FORMAT`. -- Sketches are redundant and do not represent distinct flows/aspects. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md.tmpl b/skills/sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md.tmpl deleted file mode 100644 index 88a17cc1..00000000 --- a/skills/sketch-descriptions-for-wireframes-from-product-ideas/SKILL.md.tmpl +++ /dev/null @@ -1,71 +0,0 @@ ---- -name: sketch-descriptions-for-wireframes-from-product-ideas -description: >- - Sketch descriptions for wireframes from product ideas. Use when the user needs a product - workflow for design & prototyping related to sketch descriptions for wireframes from product - ideas. Trigger terms: pm, ux, flows, design, prototyping, wireframes. ---- -# Sketch descriptions for wireframes from product ideas - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Sketch descriptions for wireframes from product ideas**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_IDEA}} -- {{ADDITIONAL_DETAILS}} - - -GOAL -Produce a high-quality deliverable for: Sketch descriptions for wireframes from product ideas. -Success metric: -- Produces 3-5 detailed sketch descriptions covering distinct product flows/aspects. -- Each sketch includes layout, interaction flow, friction reduction, and design variations. -- Output is specific enough for a visual designer to create wireframes/mockups directly. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_IDEA}}` and `{{ADDITIONAL_DETAILS}}`; if details are missing, state assumptions explicitly. -- Generate 3-5 sketches, each focused on a distinct flow/aspect (not minor variants of the same screen). -- For each sketch include: - - Title/identifier - - What the sketch represents - - Key UI elements and placement - - User flow and interaction points - - At least one meaningful variation/alternative -- Incorporate user-centric design, friction reduction, onboarding considerations, consistency, and scalability. -- Do not restate input prompts verbatim in the output. - -FORMAT -Return exactly this structure: - - - -[Sketch title] -[What this sketch represents] -[Key elements and placement] -[Start point -> key actions -> completion point] -[How this sketch reduces friction/pain points] -[Alternative design directions or variants] - -[Repeat `` for each sketch; total 3-5 sketches] - - -FAILURE -- Root tag `` or child `` sections are missing, malformed, or incomplete. -- Fewer than 3 or more than 5 sketches are provided. -- Any sketch is missing one or more required fields from `FORMAT`. -- Sketches are redundant and do not represent distinct flows/aspects. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/sketch-descriptions-for-wireframes-from-product-ideas/agents/openai.yaml b/skills/sketch-descriptions-for-wireframes-from-product-ideas/agents/openai.yaml deleted file mode 100644 index 11889a5f..00000000 --- a/skills/sketch-descriptions-for-wireframes-from-product-ideas/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Sketch descriptions for wireframes from product ideas" - short_description: "Sketch descriptions for wireframes from product ideas. Use when the user needs a product workflow for design &..." - brand_color: "#DB2777" - default_prompt: "Use $sketch-descriptions-for-wireframes-from-product-ideas with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/sketch-descriptions-for-wireframes-from-product-ideas/productize.json b/skills/sketch-descriptions-for-wireframes-from-product-ideas/productize.json deleted file mode 100644 index ea8335ba..00000000 --- a/skills/sketch-descriptions-for-wireframes-from-product-ideas/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Sketch descriptions for wireframes from product ideas", - "category": "Design", - "lifecycle": "Design", - "tags": [ - "sketch-descriptions-for-wireframes-from-product-ideas", - "sketch", - "descriptions", - "wireframes", - "ideas", - "design", - "prototyping" - ], - "use_when": "Sketch descriptions for wireframes from product ideas. Use when the user needs a product workflow for design & prototyping related to sketch descriptions for wireframes from product ideas. Trigger terms: pm, ux, flows, design, prototyping, wireframes.", - "do_not_use_when": "Do not use Sketch descriptions for wireframes from product ideas when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Sketch descriptions for wireframes from product ideas UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "sketch-descriptions-for-wireframes-from-product-ideas", - "sketch", - "descriptions", - "wireframes", - "ideas", - "design", - "prototyping" - ], - "framework_fit": "Sketch descriptions for wireframes from product ideas fits Design work in the Design lifecycle when the user needs Sketch descriptions for wireframes from product ideas UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Sketch descriptions for wireframes from product ideas UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Sketch descriptions for wireframes from product ideas as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Sketch descriptions for wireframes from product ideas when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $sketch-descriptions-for-wireframes-from-product-ideas to turn this sketch context into a decision-ready Sketch descriptions for wireframes from product ideas UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Sketch descriptions for wireframes from product ideas UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/skimmable-writing-transformation/SKILL.md b/skills/skimmable-writing-transformation/SKILL.md deleted file mode 100644 index ed21192c..00000000 --- a/skills/skimmable-writing-transformation/SKILL.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -name: skimmable-writing-transformation -description: >- - Skimmable writing transformation. Use when the user needs a product workflow for - presentation & communication related to skimmable writing transformation. Trigger terms: - writing, editing, clarity, structure. ---- - - - -# Skimmable writing transformation - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `skimmable-writing-transformation` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Skimmable writing transformation stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Skimmable writing transformation**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Skimmable writing transformation. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are a writing transformer. Rewrite the provided content so it is crystal-clear and easy to skim by using explicit signposting language throughout. - -## Inputs - -* CONTENT: the raw text to transform -* AUDIENCE: who this is for (e.g., execs, peers, customers) -* GOAL: what you want the audience to think/do after reading -* LENGTH (optional): target word count - -## Output Requirements - -Produce a single, self-contained text that: - -* Opens with the point and why it matters (Bottom Line Up Front). -* Uses full sentences (not fragments). -* Is concise (high information density; cut fluff, keep meaning). -* Minimizes formatting; prefer words over bolding. -* Is organized with numbered sections and clear transitions. - -## Structure Template (use/adjust as needed) - -1. In short, [1-sentence core point + why it matters to AUDIENCE]. -2. Context: [Becauseโ€ฆ] [What problem/opportunity this addresses.] -3. What weโ€™re proposing: First, โ€ฆ Second, โ€ฆ Third, โ€ฆ -4. Evidence & reasoning: Because โ€ฆ For example, โ€ฆ Therefore, โ€ฆ -5. Risks & objections (MOO): You might be wondering, โ€ฆ Our approach: โ€ฆ -6. As a next step, [specific ask, owner, and timing]. -7. If you remember one thing, [1-sentence takeaway]. - -## Signposting Palette (use liberally to guide the reader) - -Use these phrases to make the structure explicit: - -* In short, / Bottom line: (thesis) -* Context: / Hereโ€™s why this matters: (setup) -* First, Second, Third, (ordered points) -* Because โ€ฆ / Therefore โ€ฆ (logic) -* For example, (illustration) -* In contrast, / However, (turn) -* As a result, (implication) -* You might be wondering, / A fair concern is, (anticipate objections) -* So what? / What this means is, (meaning) -* As a next step, (action) -* If you remember one thing, (recap) - -## Editing Pass (do this before finalizing) - -Before you present the final answer: - -* Cut 20โ€“40% of words that donโ€™t change meaning. -* Replace jargon with plain terms suitable for AUDIENCE. -* Promote specifics: dates, owners, numbers. -* Turn bullets into sentences where logic needs to be explicit. -* Check flow: each paragraph should begin with a signpost that previews its role. -* MOO (Most Obvious Objection) check: add one sentence that answers the most obvious objection. - -## Edge Cases - -* If CONTENT is very short, still add โ€œIn short,โ€ and โ€œAs a next step,โ€ lines. -* If evidence is missing, write โ€œBecause โ€ฆโ€ using first-principles reasoning and add โ€œFor example โ€ฆโ€ with a plausible illustration, clearly labeled as such. -* If GOAL is unclear, infer a reasonable one and make it explicit in the opening. - -## Style Constraints - -* Tone: direct, neutral-to-supportive, no hype. -* Sentences: mostly short to medium; one idea per sentence. -* Prefer verbs over nouns; use active voice. - ---- - -Now transform: - -* AUDIENCE: [insert] -* GOAL: [insert] -* LENGTH: [optional] -* CONTENT: - [insert] - - -FORMAT -Return exactly this structure: - - -[Provide the complete response with clear sections that satisfy all required tasks.] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/skimmable-writing-transformation/SKILL.md.tmpl b/skills/skimmable-writing-transformation/SKILL.md.tmpl deleted file mode 100644 index abf417b7..00000000 --- a/skills/skimmable-writing-transformation/SKILL.md.tmpl +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: skimmable-writing-transformation -description: >- - Skimmable writing transformation. Use when the user needs a product workflow for - presentation & communication related to skimmable writing transformation. Trigger terms: - writing, editing, clarity, structure. ---- -# Skimmable writing transformation - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Skimmable writing transformation**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Skimmable writing transformation. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are a writing transformer. Rewrite the provided content so it is crystal-clear and easy to skim by using explicit signposting language throughout. - -## Inputs - -* CONTENT: the raw text to transform -* AUDIENCE: who this is for (e.g., execs, peers, customers) -* GOAL: what you want the audience to think/do after reading -* LENGTH (optional): target word count - -## Output Requirements - -Produce a single, self-contained text that: - -* Opens with the point and why it matters (Bottom Line Up Front). -* Uses full sentences (not fragments). -* Is concise (high information density; cut fluff, keep meaning). -* Minimizes formatting; prefer words over bolding. -* Is organized with numbered sections and clear transitions. - -## Structure Template (use/adjust as needed) - -1. In short, [1-sentence core point + why it matters to AUDIENCE]. -2. Context: [Becauseโ€ฆ] [What problem/opportunity this addresses.] -3. What weโ€™re proposing: First, โ€ฆ Second, โ€ฆ Third, โ€ฆ -4. Evidence & reasoning: Because โ€ฆ For example, โ€ฆ Therefore, โ€ฆ -5. Risks & objections (MOO): You might be wondering, โ€ฆ Our approach: โ€ฆ -6. As a next step, [specific ask, owner, and timing]. -7. If you remember one thing, [1-sentence takeaway]. - -## Signposting Palette (use liberally to guide the reader) - -Use these phrases to make the structure explicit: - -* In short, / Bottom line: (thesis) -* Context: / Hereโ€™s why this matters: (setup) -* First, Second, Third, (ordered points) -* Because โ€ฆ / Therefore โ€ฆ (logic) -* For example, (illustration) -* In contrast, / However, (turn) -* As a result, (implication) -* You might be wondering, / A fair concern is, (anticipate objections) -* So what? / What this means is, (meaning) -* As a next step, (action) -* If you remember one thing, (recap) - -## Editing Pass (do this before finalizing) - -Before you present the final answer: - -* Cut 20โ€“40% of words that donโ€™t change meaning. -* Replace jargon with plain terms suitable for AUDIENCE. -* Promote specifics: dates, owners, numbers. -* Turn bullets into sentences where logic needs to be explicit. -* Check flow: each paragraph should begin with a signpost that previews its role. -* MOO (Most Obvious Objection) check: add one sentence that answers the most obvious objection. - -## Edge Cases - -* If CONTENT is very short, still add โ€œIn short,โ€ and โ€œAs a next step,โ€ lines. -* If evidence is missing, write โ€œBecause โ€ฆโ€ using first-principles reasoning and add โ€œFor example โ€ฆโ€ with a plausible illustration, clearly labeled as such. -* If GOAL is unclear, infer a reasonable one and make it explicit in the opening. - -## Style Constraints - -* Tone: direct, neutral-to-supportive, no hype. -* Sentences: mostly short to medium; one idea per sentence. -* Prefer verbs over nouns; use active voice. - ---- - -Now transform: - -* AUDIENCE: [insert] -* GOAL: [insert] -* LENGTH: [optional] -* CONTENT: - [insert] - - -FORMAT -Return exactly this structure: - - -[Provide the complete response with clear sections that satisfy all required tasks.] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/skimmable-writing-transformation/agents/openai.yaml b/skills/skimmable-writing-transformation/agents/openai.yaml deleted file mode 100644 index 5e85dce9..00000000 --- a/skills/skimmable-writing-transformation/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Skimmable writing transformation" - short_description: "Skimmable writing transformation. Use when the user needs a product workflow for presentation & communication..." - brand_color: "#0891B2" - default_prompt: "Use $skimmable-writing-transformation with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/skimmable-writing-transformation/productize.json b/skills/skimmable-writing-transformation/productize.json deleted file mode 100644 index 757fc892..00000000 --- a/skills/skimmable-writing-transformation/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Skimmable writing transformation", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "skimmable-writing-transformation", - "skimmable", - "writing", - "transformation", - "presentation", - "communication", - "stakeholder" - ], - "use_when": "Skimmable writing transformation. Use when the user needs a product workflow for presentation & communication related to skimmable writing transformation. Trigger terms: writing, editing, clarity, structure.", - "do_not_use_when": "Do not use Skimmable writing transformation when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Skimmable writing transformation stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "skimmable-writing-transformation", - "skimmable", - "writing", - "transformation", - "presentation", - "communication", - "stakeholder" - ], - "framework_fit": "Skimmable writing transformation fits Stakeholder Communication work in the Align lifecycle when the user needs Skimmable writing transformation stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Skimmable writing transformation stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Skimmable writing transformation as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Skimmable writing transformation when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $skimmable-writing-transformation to turn this skimmable context into a decision-ready Skimmable writing transformation stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Skimmable writing transformation stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/slide-decks-from-problem-statements-and-context/SKILL.md b/skills/slide-decks-from-problem-statements-and-context/SKILL.md deleted file mode 100644 index 41628047..00000000 --- a/skills/slide-decks-from-problem-statements-and-context/SKILL.md +++ /dev/null @@ -1,165 +0,0 @@ ---- -name: slide-decks-from-problem-statements-and-context -description: >- - Slide decks from problem statements and context. Use when the user needs a product workflow - for presentation & communication related to slide decks from problem statements and context. - Trigger terms: presentations, storytelling, communication, decision-making, - product-management. ---- - - - -# Slide decks from problem statements and context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `slide-decks-from-problem-statements-and-context` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Slide decks from problem statements and context stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Slide decks from problem statements and context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} -- {{ADDITIONAL_CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Slide decks from problem statements and context. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are now the world's most convincing, clear, and intelligent management consultant. Your task is to create the most succinct, data-packed, informative, and convincing PowerPoint/slide deck in the world. You will craft guidance for each slide, including layout ideas and specific placement of elements on the canvas. - -You will be given a problem statement and additional context. Use this information to create your slide deck outline. - -Problem Statement: - -{{PROBLEM_STATEMENT}} - - -Additional Context: - -{{ADDITIONAL_CONTEXT}} - - -Follow these guidelines to create your slide deck: - -1. **Overall Structure:** - - Use the "What, So What, Now What" flow of logic. - - Comply with the Pyramid Principle by Barbara Minto/McKinsey. - -2. **Slide Flow:** - - Each slide must answer the question raised by the previous slide. - - Ensure a logical flow towards the recommended conclusion. - -3. **Individual Slide Creation:** - - Every slide should have a title in the form of a question. - - The content of the slide should answer that question with supporting details. - - Craft specific layout guidance for each slide, stating what element goes where on the canvas. - -4. **Content Guidelines:** - - Be concise and data-driven. - - Ensure each piece of information serves a purpose in building your argument. - - Use visuals, charts, and graphs where appropriate to convey information effectively. - -Now, create your slide deck outline. For each slide, provide the following: - -Begin your outline with an executive summary slide and end with a conclusion and next steps slide. Aim for 8โ€“12 slides in total, depending on the complexity of the problem statement. - -After creating your slide deck outline, provide a brief explanation of how your outline adheres to the "What, So What, Now What" structure and the Pyramid Principle. - -Present your complete slide deck outline and explanation within `` tags. - - -FORMAT -Return exactly this structure: - - -Slide [Number]: [Question Title] -Purpose: [Brief description of the slide's purpose] -Key Points: -- [Point 1] -- [Point 2] -- [Point 3] - -Layout Guidance: -[Describe the layout, including placement of title, key points, and any visual elements] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/slide-decks-from-problem-statements-and-context/SKILL.md.tmpl b/skills/slide-decks-from-problem-statements-and-context/SKILL.md.tmpl deleted file mode 100644 index 876a0ce0..00000000 --- a/skills/slide-decks-from-problem-statements-and-context/SKILL.md.tmpl +++ /dev/null @@ -1,106 +0,0 @@ ---- -name: slide-decks-from-problem-statements-and-context -description: >- - Slide decks from problem statements and context. Use when the user needs a product workflow - for presentation & communication related to slide decks from problem statements and context. - Trigger terms: presentations, storytelling, communication, decision-making, - product-management. ---- -# Slide decks from problem statements and context - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Slide decks from problem statements and context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} -- {{ADDITIONAL_CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Slide decks from problem statements and context. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Follow these task requirements: - -You are now the world's most convincing, clear, and intelligent management consultant. Your task is to create the most succinct, data-packed, informative, and convincing PowerPoint/slide deck in the world. You will craft guidance for each slide, including layout ideas and specific placement of elements on the canvas. - -You will be given a problem statement and additional context. Use this information to create your slide deck outline. - -Problem Statement: - -{{PROBLEM_STATEMENT}} - - -Additional Context: - -{{ADDITIONAL_CONTEXT}} - - -Follow these guidelines to create your slide deck: - -1. **Overall Structure:** - - Use the "What, So What, Now What" flow of logic. - - Comply with the Pyramid Principle by Barbara Minto/McKinsey. - -2. **Slide Flow:** - - Each slide must answer the question raised by the previous slide. - - Ensure a logical flow towards the recommended conclusion. - -3. **Individual Slide Creation:** - - Every slide should have a title in the form of a question. - - The content of the slide should answer that question with supporting details. - - Craft specific layout guidance for each slide, stating what element goes where on the canvas. - -4. **Content Guidelines:** - - Be concise and data-driven. - - Ensure each piece of information serves a purpose in building your argument. - - Use visuals, charts, and graphs where appropriate to convey information effectively. - -Now, create your slide deck outline. For each slide, provide the following: - -Begin your outline with an executive summary slide and end with a conclusion and next steps slide. Aim for 8โ€“12 slides in total, depending on the complexity of the problem statement. - -After creating your slide deck outline, provide a brief explanation of how your outline adheres to the "What, So What, Now What" structure and the Pyramid Principle. - -Present your complete slide deck outline and explanation within `` tags. - - -FORMAT -Return exactly this structure: - - -Slide [Number]: [Question Title] -Purpose: [Brief description of the slide's purpose] -Key Points: -- [Point 1] -- [Point 2] -- [Point 3] - -Layout Guidance: -[Describe the layout, including placement of title, key points, and any visual elements] - - -FAILURE -- Output misses required sections, steps, or reasoning required by ``. -- Required format/schema is missing, malformed, or incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/slide-decks-from-problem-statements-and-context/agents/openai.yaml b/skills/slide-decks-from-problem-statements-and-context/agents/openai.yaml deleted file mode 100644 index 2a4da6ba..00000000 --- a/skills/slide-decks-from-problem-statements-and-context/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Slide decks from problem statements and context" - short_description: "Slide decks from problem statements and context. Use when the user needs a product workflow for presentation &..." - brand_color: "#0891B2" - default_prompt: "Use $slide-decks-from-problem-statements-and-context with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/slide-decks-from-problem-statements-and-context/productize.json b/skills/slide-decks-from-problem-statements-and-context/productize.json deleted file mode 100644 index efaf9075..00000000 --- a/skills/slide-decks-from-problem-statements-and-context/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Slide decks from problem statements and context", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "slide-decks-from-problem-statements-and-context", - "slide", - "decks", - "problem", - "statements", - "context" - ], - "use_when": "Slide decks from problem statements and context. Use when the user needs a product workflow for presentation & communication related to slide decks from problem statements and context. Trigger terms: presentations, storytelling, communication, decision-making, product-management.", - "do_not_use_when": "Do not use Slide decks from problem statements and context when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Slide decks from problem statements and context stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "slide-decks-from-problem-statements-and-context", - "slide", - "decks", - "problem", - "statements", - "context" - ], - "framework_fit": "Slide decks from problem statements and context fits Stakeholder Communication work in the Align lifecycle when the user needs Slide decks from problem statements and context stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Slide decks from problem statements and context stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Slide decks from problem statements and context as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Slide decks from problem statements and context when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $slide-decks-from-problem-statements-and-context to turn this slide context into a decision-ready Slide decks from problem statements and context stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Slide decks from problem statements and context stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/solution-anti-patterns-from-customer-problem-analysis/SKILL.md b/skills/solution-anti-patterns-from-customer-problem-analysis/SKILL.md deleted file mode 100644 index 38563509..00000000 --- a/skills/solution-anti-patterns-from-customer-problem-analysis/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: solution-anti-patterns-from-customer-problem-analysis -description: >- - Solution anti-patterns from customer problem analysis. Use when the user needs a product - workflow for decision making related to solution anti-patterns from customer problem - analysis. Trigger terms: pm, decision-making, critical-thinking, anti-patterns. ---- - - - -# Solution anti-patterns from customer problem analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `solution-anti-patterns-from-customer-problem-analysis` -- **Lifecycle**: Think -- **Category**: Strategy -- **Primary artifact**: Solution anti-patterns from customer problem analysis decision-framing brief with issue tree, assumptions, options, and recommended next step - -Use this skill to run the Productize prompt contract for **Solution anti-patterns from customer problem analysis**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CUSTOMER_NOTES}} - - -GOAL -Produce a high-quality deliverable for: Solution anti-patterns from customer problem analysis. -Success metric: -- Produces exactly 3 plausible but fundamentally flawed solutions derived from the customer problem context. -- Each flawed solution is clearly mapped to why it fails (or worsens outcomes) with concrete evidence from inputs. -- Output follows the required schema exactly. - -CONSTRAINTS -- Use only `{{CUSTOMER_NOTES}}`; if details are missing, state assumptions explicitly. -- Analyze first, then propose flawed solutions; do not skip analysis steps. -- Keep flaws subtle and realistic (not absurd/comedic), and tie them to customer context. -- Ensure each flawed solution is implementable on the surface but strategically wrong. -- Cover short-term and long-term consequences, stakeholder impacts, and implementation constraints. - -FORMAT -Return exactly this structure: - - -1. Notes breakdown: [Key points, assumptions, implicit needs] -2. Core problems: [Primary problems to address] -3. Stakeholders: [Stakeholder -> interests] -4. Failure-prone areas: [Where solutions can go wrong] -5. Consequences: [Short-term and long-term consequences to watch] -6. Constraints: [Resource and implementation constraints] -7. Flawed-approach brainstorm: [Candidate anti-pattern directions] - - - -1. [Brief description of flawed solution 1] -2. [Brief description of flawed solution 2] -3. [Brief description of flawed solution 3] - - - -1. [Why solution 1 is a poor choice: misread need, hidden downside, likely failure mode, consequence] -2. [Why solution 2 is a poor choice: misread need, hidden downside, likely failure mode, consequence] -3. [Why solution 3 is a poor choice: misread need, hidden downside, likely failure mode, consequence] - - -FAILURE -- Any required section in `FORMAT` is missing, malformed, or incomplete. -- Not exactly 3 flawed solutions. -- Explanations do not map 1:1 to the listed solutions. -- Claims are generic or not grounded in provided inputs. -- Flaws are absurd/comedic instead of plausible and subtle. -- Assumptions are used but not explicitly stated. diff --git a/skills/solution-anti-patterns-from-customer-problem-analysis/SKILL.md.tmpl b/skills/solution-anti-patterns-from-customer-problem-analysis/SKILL.md.tmpl deleted file mode 100644 index 9a0d27ef..00000000 --- a/skills/solution-anti-patterns-from-customer-problem-analysis/SKILL.md.tmpl +++ /dev/null @@ -1,74 +0,0 @@ ---- -name: solution-anti-patterns-from-customer-problem-analysis -description: >- - Solution anti-patterns from customer problem analysis. Use when the user needs a product - workflow for decision making related to solution anti-patterns from customer problem - analysis. Trigger terms: pm, decision-making, critical-thinking, anti-patterns. ---- -# Solution anti-patterns from customer problem analysis - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Solution anti-patterns from customer problem analysis**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CUSTOMER_NOTES}} - - -GOAL -Produce a high-quality deliverable for: Solution anti-patterns from customer problem analysis. -Success metric: -- Produces exactly 3 plausible but fundamentally flawed solutions derived from the customer problem context. -- Each flawed solution is clearly mapped to why it fails (or worsens outcomes) with concrete evidence from inputs. -- Output follows the required schema exactly. - -CONSTRAINTS -- Use only `{{CUSTOMER_NOTES}}`; if details are missing, state assumptions explicitly. -- Analyze first, then propose flawed solutions; do not skip analysis steps. -- Keep flaws subtle and realistic (not absurd/comedic), and tie them to customer context. -- Ensure each flawed solution is implementable on the surface but strategically wrong. -- Cover short-term and long-term consequences, stakeholder impacts, and implementation constraints. - -FORMAT -Return exactly this structure: - - -1. Notes breakdown: [Key points, assumptions, implicit needs] -2. Core problems: [Primary problems to address] -3. Stakeholders: [Stakeholder -> interests] -4. Failure-prone areas: [Where solutions can go wrong] -5. Consequences: [Short-term and long-term consequences to watch] -6. Constraints: [Resource and implementation constraints] -7. Flawed-approach brainstorm: [Candidate anti-pattern directions] - - - -1. [Brief description of flawed solution 1] -2. [Brief description of flawed solution 2] -3. [Brief description of flawed solution 3] - - - -1. [Why solution 1 is a poor choice: misread need, hidden downside, likely failure mode, consequence] -2. [Why solution 2 is a poor choice: misread need, hidden downside, likely failure mode, consequence] -3. [Why solution 3 is a poor choice: misread need, hidden downside, likely failure mode, consequence] - - -FAILURE -- Any required section in `FORMAT` is missing, malformed, or incomplete. -- Not exactly 3 flawed solutions. -- Explanations do not map 1:1 to the listed solutions. -- Claims are generic or not grounded in provided inputs. -- Flaws are absurd/comedic instead of plausible and subtle. -- Assumptions are used but not explicitly stated. diff --git a/skills/solution-anti-patterns-from-customer-problem-analysis/agents/openai.yaml b/skills/solution-anti-patterns-from-customer-problem-analysis/agents/openai.yaml deleted file mode 100644 index f02ea99f..00000000 --- a/skills/solution-anti-patterns-from-customer-problem-analysis/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Solution anti-patterns from customer problem analysis" - short_description: "Solution anti-patterns from customer problem analysis. Use when the user needs a product workflow for decision..." - brand_color: "#059669" - default_prompt: "Use $solution-anti-patterns-from-customer-problem-analysis with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/solution-anti-patterns-from-customer-problem-analysis/productize.json b/skills/solution-anti-patterns-from-customer-problem-analysis/productize.json deleted file mode 100644 index c4bb7e11..00000000 --- a/skills/solution-anti-patterns-from-customer-problem-analysis/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Solution anti-patterns from customer problem analysis", - "category": "Strategy", - "lifecycle": "Think", - "tags": [ - "solution-anti-patterns-from-customer-problem-analysis", - "solution", - "anti", - "patterns", - "customer", - "problem" - ], - "use_when": "Solution anti-patterns from customer problem analysis. Use when the user needs a product workflow for decision making related to solution anti-patterns from customer problem analysis. Trigger terms: pm, decision-making, critical-thinking, anti-patterns.", - "do_not_use_when": "Do not use Solution anti-patterns from customer problem analysis when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Solution anti-patterns from customer problem analysis decision-framing brief with issue tree, assumptions, options, and recommended next step", - "routing_signals": [ - "solution-anti-patterns-from-customer-problem-analysis", - "solution", - "anti", - "patterns", - "customer", - "problem" - ], - "framework_fit": "Solution anti-patterns from customer problem analysis fits Strategy work in the Think lifecycle when the user needs Solution anti-patterns from customer problem analysis decision-framing brief with issue tree, assumptions, options, and recommended next step and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Solution anti-patterns from customer problem analysis decision-framing brief with issue tree, assumptions, options, and recommended next step without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Solution anti-patterns from customer problem analysis as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Solution anti-patterns from customer problem analysis when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $solution-anti-patterns-from-customer-problem-analysis to turn this solution context into a decision-ready Solution anti-patterns from customer problem analysis decision-framing brief with issue tree, assumptions, options, and recommended next step.", - "expected_artifact": "Solution anti-patterns from customer problem analysis decision-framing brief with issue tree, assumptions, options, and recommended next step" - } - ] -} diff --git a/skills/solution-design-for-edge-cases-in-product-development/SKILL.md b/skills/solution-design-for-edge-cases-in-product-development/SKILL.md deleted file mode 100644 index 520e51f2..00000000 --- a/skills/solution-design-for-edge-cases-in-product-development/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: solution-design-for-edge-cases-in-product-development -description: >- - Solution design for edge cases in product development. Use when the user needs a product - workflow for design & prototyping related to solution design for edge cases in product - development. Trigger terms: ux, edge-cases, product-design, tradeoffs. ---- - - - -# Solution design for edge cases in product development - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `solution-design-for-edge-cases-in-product-development` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Solution design for edge cases in product development UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Solution design for edge cases in product development**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{EDGE_CASE_SCENARIO}} - - -GOAL -Produce a high-quality deliverable for: Solution design for edge cases in product development. -Success metric: -- Clearly explains why the scenario is rare but critical and its user/business impact. -- Proposes and evaluates at least 3 distinct solution approaches. -- Recommends a balanced solution that resolves the edge case without overcomplicating the core flow. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{EDGE_CASE_SCENARIO}}`; if details are missing, state assumptions explicitly. -- Start with scenario diagnosis before solutioning. -- Generate at least 3 approaches spanning minimal to comprehensive change. -- Evaluate each approach on: - - effectiveness for the edge case, - - impact on core users, - - implementation complexity, - - scalability/risk. -- Recommend one approach with clear tradeoff rationale. -- Prioritize minimal added complexity to the primary user journey. - -FORMAT -Return exactly this structure: - - - -- Core issue: [What fails and why] -- Why rare but critical: [Frequency + severity] -- Affected users and impact: [Who is impacted and consequence] - - - -1. [Option name] - [Approach summary] -2. [Option name] - [Approach summary] -3. [Option name] - [Approach summary] -[Optional additional options] - - - -- [Option name]: - - Pros: [Bullets] - - Cons: [Bullets] - - Complexity: [Low/Medium/High + note] - - Core experience impact: [Low/Medium/High + note] - - Scalability: [Assessment] -- [Repeat for each option] - - - -Briefly describe your recommended solution in 2-3 sentences. - - - -Explain your reasoning for choosing this solution, including: -- How it addresses the edge case -- Why it's preferable to other options -- How it minimizes impact on the core experience - - - -Provide a high-level overview of how to implement this solution, including: -- Any necessary changes to the user interface -- Backend modifications required -- Potential challenges in implementation and how to address them - - - -Suggest how to communicate this change to users, if necessary. This may include: -- Updates to documentation -- In-app notifications or tooltips -- Changes to onboarding processes - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 solution options are provided. -- No explicit evaluation is provided for one or more options. -- Recommendation is not traceable to the option tradeoff analysis. -- Recommendation over-engineers the core flow without justification. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/solution-design-for-edge-cases-in-product-development/SKILL.md.tmpl b/skills/solution-design-for-edge-cases-in-product-development/SKILL.md.tmpl deleted file mode 100644 index 2ef1057c..00000000 --- a/skills/solution-design-for-edge-cases-in-product-development/SKILL.md.tmpl +++ /dev/null @@ -1,109 +0,0 @@ ---- -name: solution-design-for-edge-cases-in-product-development -description: >- - Solution design for edge cases in product development. Use when the user needs a product - workflow for design & prototyping related to solution design for edge cases in product - development. Trigger terms: ux, edge-cases, product-design, tradeoffs. ---- -# Solution design for edge cases in product development - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Solution design for edge cases in product development**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{EDGE_CASE_SCENARIO}} - - -GOAL -Produce a high-quality deliverable for: Solution design for edge cases in product development. -Success metric: -- Clearly explains why the scenario is rare but critical and its user/business impact. -- Proposes and evaluates at least 3 distinct solution approaches. -- Recommends a balanced solution that resolves the edge case without overcomplicating the core flow. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{EDGE_CASE_SCENARIO}}`; if details are missing, state assumptions explicitly. -- Start with scenario diagnosis before solutioning. -- Generate at least 3 approaches spanning minimal to comprehensive change. -- Evaluate each approach on: - - effectiveness for the edge case, - - impact on core users, - - implementation complexity, - - scalability/risk. -- Recommend one approach with clear tradeoff rationale. -- Prioritize minimal added complexity to the primary user journey. - -FORMAT -Return exactly this structure: - - - -- Core issue: [What fails and why] -- Why rare but critical: [Frequency + severity] -- Affected users and impact: [Who is impacted and consequence] - - - -1. [Option name] - [Approach summary] -2. [Option name] - [Approach summary] -3. [Option name] - [Approach summary] -[Optional additional options] - - - -- [Option name]: - - Pros: [Bullets] - - Cons: [Bullets] - - Complexity: [Low/Medium/High + note] - - Core experience impact: [Low/Medium/High + note] - - Scalability: [Assessment] -- [Repeat for each option] - - - -Briefly describe your recommended solution in 2-3 sentences. - - - -Explain your reasoning for choosing this solution, including: -- How it addresses the edge case -- Why it's preferable to other options -- How it minimizes impact on the core experience - - - -Provide a high-level overview of how to implement this solution, including: -- Any necessary changes to the user interface -- Backend modifications required -- Potential challenges in implementation and how to address them - - - -Suggest how to communicate this change to users, if necessary. This may include: -- Updates to documentation -- In-app notifications or tooltips -- Changes to onboarding processes - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 solution options are provided. -- No explicit evaluation is provided for one or more options. -- Recommendation is not traceable to the option tradeoff analysis. -- Recommendation over-engineers the core flow without justification. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/solution-design-for-edge-cases-in-product-development/agents/openai.yaml b/skills/solution-design-for-edge-cases-in-product-development/agents/openai.yaml deleted file mode 100644 index 65d7d8da..00000000 --- a/skills/solution-design-for-edge-cases-in-product-development/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Solution design for edge cases in product development" - short_description: "Solution design for edge cases in product development. Use when the user needs a product workflow for design &..." - brand_color: "#DB2777" - default_prompt: "Use $solution-design-for-edge-cases-in-product-development with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/solution-design-for-edge-cases-in-product-development/productize.json b/skills/solution-design-for-edge-cases-in-product-development/productize.json deleted file mode 100644 index 0eaf05df..00000000 --- a/skills/solution-design-for-edge-cases-in-product-development/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Solution design for edge cases in product development", - "category": "Design", - "lifecycle": "Design", - "tags": [ - "solution-design-for-edge-cases-in-product-development", - "solution", - "design", - "edge", - "cases", - "development" - ], - "use_when": "Solution design for edge cases in product development. Use when the user needs a product workflow for design & prototyping related to solution design for edge cases in product development. Trigger terms: ux, edge-cases, product-design, tradeoffs.", - "do_not_use_when": "Do not use Solution design for edge cases in product development when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Solution design for edge cases in product development UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "solution-design-for-edge-cases-in-product-development", - "solution", - "design", - "edge", - "cases", - "development" - ], - "framework_fit": "Solution design for edge cases in product development fits Design work in the Design lifecycle when the user needs Solution design for edge cases in product development UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Solution design for edge cases in product development UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Solution design for edge cases in product development as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Solution design for edge cases in product development when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $solution-design-for-edge-cases-in-product-development to turn this solution context into a decision-ready Solution design for edge cases in product development UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Solution design for edge cases in product development UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/spec-writing/SKILL.md b/skills/spec-writing/SKILL.md deleted file mode 100644 index fb0108f8..00000000 --- a/skills/spec-writing/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: spec-writing -description: >- - Convert an approved PRD or clear requirements into an implementation-ready technical spec - with scope, interfaces, and acceptance criteria. ---- - - - -# Spec Writing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `spec-writing` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Implementation-ready technical spec with interfaces, acceptance criteria, and verification plan - -Use this skill to produce an implementation-ready spec before planning or coding. - -## Artifact Format - -Use Markdown for compact specs that should stay easy to diff in the repo. Use -self-contained HTML when the spec is long, visual, diagram-heavy, shareable, or -expected to become a reference artifact for another implementation session. - -When the implementation will likely contain unresolved ambiguity, include a note -that `$implementation-notes` should maintain `implementation-notes.md` or -`implementation-notes.html` during build. - -## The Process - -### Step 1: Validate inputs - -Require one of: -- approved PRD -- clear requirements with goals and constraints - -If inputs are missing or ambiguous, list assumptions and open questions first. - -### Step 2: Define scope boundaries - -Document: -- in scope -- out of scope -- constraints (time, dependencies, compliance, platform) - -### Step 3: Define solution design - -Specify: -- architecture overview (high-level components) -- interfaces/contracts -- data model changes -- rollout and migration approach - -### Step 4: Define acceptance and verification - -Include: -- acceptance criteria (testable) -- non-functional expectations (performance, security, reliability) -- verification commands/checks required before completion - -## Output Format - -```markdown -# [Feature Name] Technical Spec - -## Goal -[What this spec delivers and why] - -## Scope -- In scope: -- Out of scope: -- Constraints: - -## Design -- Architecture: -- Interfaces/contracts: -- Data model changes: -- Migration/rollout: - -## Risks and Dependencies -- Risks: -- Dependencies: -- Mitigations: - -## Acceptance Criteria -- AC1: -- AC2: -- AC3: - -## Verification Plan -- Required checks: -- Commands: -- Evidence to capture: - -## Implementation Notes Plan -- Notes file: -- Ambiguity areas to watch: -- Decisions that require user confirmation: - -## Open Questions -- Q1: -- Q2: -``` - -## Quality Bar - -- No vague placeholders in final output -- Acceptance criteria must be measurable -- Verification plan must include explicit commands - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/spec-writing/SKILL.md.tmpl b/skills/spec-writing/SKILL.md.tmpl deleted file mode 100644 index 191e7a0c..00000000 --- a/skills/spec-writing/SKILL.md.tmpl +++ /dev/null @@ -1,111 +0,0 @@ ---- -name: spec-writing -description: >- - Convert an approved PRD or clear requirements into an implementation-ready technical spec - with scope, interfaces, and acceptance criteria. ---- -# Spec Writing - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to produce an implementation-ready spec before planning or coding. - -## Artifact Format - -Use Markdown for compact specs that should stay easy to diff in the repo. Use -self-contained HTML when the spec is long, visual, diagram-heavy, shareable, or -expected to become a reference artifact for another implementation session. - -When the implementation will likely contain unresolved ambiguity, include a note -that `$implementation-notes` should maintain `implementation-notes.md` or -`implementation-notes.html` during build. - -## The Process - -### Step 1: Validate inputs - -Require one of: -- approved PRD -- clear requirements with goals and constraints - -If inputs are missing or ambiguous, list assumptions and open questions first. - -### Step 2: Define scope boundaries - -Document: -- in scope -- out of scope -- constraints (time, dependencies, compliance, platform) - -### Step 3: Define solution design - -Specify: -- architecture overview (high-level components) -- interfaces/contracts -- data model changes -- rollout and migration approach - -### Step 4: Define acceptance and verification - -Include: -- acceptance criteria (testable) -- non-functional expectations (performance, security, reliability) -- verification commands/checks required before completion - -## Output Format - -```markdown -# [Feature Name] Technical Spec - -## Goal -[What this spec delivers and why] - -## Scope -- In scope: -- Out of scope: -- Constraints: - -## Design -- Architecture: -- Interfaces/contracts: -- Data model changes: -- Migration/rollout: - -## Risks and Dependencies -- Risks: -- Dependencies: -- Mitigations: - -## Acceptance Criteria -- AC1: -- AC2: -- AC3: - -## Verification Plan -- Required checks: -- Commands: -- Evidence to capture: - -## Implementation Notes Plan -- Notes file: -- Ambiguity areas to watch: -- Decisions that require user confirmation: - -## Open Questions -- Q1: -- Q2: -``` - -## Quality Bar - -- No vague placeholders in final output -- Acceptance criteria must be measurable -- Verification plan must include explicit commands - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/spec-writing/agents/openai.yaml b/skills/spec-writing/agents/openai.yaml deleted file mode 100644 index 01d56849..00000000 --- a/skills/spec-writing/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Spec Writing" - short_description: "Convert an approved PRD or clear requirements into an implementation-ready technical spec with scope, interfaces,..." - brand_color: "#334155" - default_prompt: "Use $spec-writing with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/spec-writing/productize.json b/skills/spec-writing/productize.json deleted file mode 100644 index 87993eac..00000000 --- a/skills/spec-writing/productize.json +++ /dev/null @@ -1,48 +0,0 @@ -{ - "title": "Spec Writing", - "category": "AI Execution", - "tags": [ - "technical-spec", - "implementation-spec", - "acceptance-criteria", - "interfaces", - "verification", - "requirements", - "spec-writing", - "spec", - "writing", - "technical", - "convert", - "approved", - "prd", - "clear" - ], - "lifecycle": "Build With AI", - "use_when": "Convert an approved PRD or clear requirements into an implementation-ready technical spec with scope, interfaces, and acceptance criteria.", - "do_not_use_when": "Do not use Spec Writing when the request is mainly market strategy, research synthesis, finance modeling, or executive communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Implementation-ready technical spec with interfaces, acceptance criteria, and verification plan", - "routing_signals": [ - "spec-writing", - "spec", - "writing", - "technical", - "convert", - "approved", - "prd", - "clear", - "requirements", - "execution" - ], - "framework_fit": "Appropriate when approved product requirements need to become an agent-ready or engineer-ready technical spec with scope, interfaces, risks, acceptance criteria, and verification.", - "failure_modes": [ - "Produces Implementation-ready technical spec with interfaces, acceptance criteria, and verification plan without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats Spec Writing as generic AI Execution advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Spec Writing when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $spec-writing to turn this spec context into a decision-ready Implementation-ready technical spec with interfaces, acceptance criteria, and verification plan.", - "expected_artifact": "Implementation-ready technical spec with interfaces, acceptance criteria, and verification plan" - } - ] -} diff --git a/skills/sprint-planning/SKILL.md b/skills/sprint-planning/SKILL.md deleted file mode 100644 index 6ff58dbf..00000000 --- a/skills/sprint-planning/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: sprint-planning -description: >- - Plan a sprint by scoping work, estimating capacity, setting goals, and drafting a sprint plan. - Use when kicking off a sprint, sizing a backlog against availability, deciding P0 versus - stretch, or handling carryover. ---- - - - -# Sprint Planning - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `sprint-planning` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Sprint Planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Plan a sprint by scoping work, estimating capacity, and setting clear goals. - -## Argument Hint - -`[sprint name or date range]` - -## Usage - -```text -/sprint-planning $ARGUMENTS -``` - -## Workflow - -### 1. Gather Inputs - -Ask for or pull from connected tools: -- Team members and availability. -- Sprint dates and length. -- Prioritized backlog. -- Carryover from last sprint. -- Dependencies and blockers. -- Existing estimates if available. - -If calendar data is connected, account for PTO, holidays, on-call, and known meetings. - -### 2. Set Sprint Goal - -Write one clear sentence describing what success looks like. If the proposed backlog cannot support one coherent goal, call out that the sprint is unfocused. - -### 3. Estimate Capacity - -Calculate planned capacity and leave buffer: -- Prefer planning to 70-80 percent of realistic capacity. -- Account for interrupts and operational work. -- Make carryover explicit rather than hiding it in new work. - -### 4. Scope Backlog - -Group items: -- P0: must ship for sprint success. -- P1: should ship if capacity holds. -- P2: stretch or cutline items. - -Every item needs an owner, estimate, dependency status, and acceptance criteria or definition of done. - -### 5. Produce Sprint Plan - -Return: -- Sprint title, dates, team, and sprint goal. -- Capacity table by person. -- Sprint backlog table: priority, item, estimate, owner, dependencies. -- Planned capacity versus sprint load. -- Risks and mitigations. -- Definition of Done. -- Key dates: start, midpoint, demo, retro. - -## Rules - -- Push back on overcommitment. -- Identify what gets cut if estimates grow. -- Do not recommit carryover without understanding why it carried over. -- Keep the plan useful to engineers, not just stakeholders. diff --git a/skills/sprint-planning/SKILL.md.tmpl b/skills/sprint-planning/SKILL.md.tmpl deleted file mode 100644 index 02cd8e15..00000000 --- a/skills/sprint-planning/SKILL.md.tmpl +++ /dev/null @@ -1,74 +0,0 @@ ---- -name: sprint-planning -description: >- - Plan a sprint by scoping work, estimating capacity, setting goals, and drafting a sprint plan. - Use when kicking off a sprint, sizing a backlog against availability, deciding P0 versus - stretch, or handling carryover. ---- -# Sprint Planning - -{{PRODUCTIZE_PREAMBLE}} - -Plan a sprint by scoping work, estimating capacity, and setting clear goals. - -## Argument Hint - -`[sprint name or date range]` - -## Usage - -```text -/sprint-planning $ARGUMENTS -``` - -## Workflow - -### 1. Gather Inputs - -Ask for or pull from connected tools: -- Team members and availability. -- Sprint dates and length. -- Prioritized backlog. -- Carryover from last sprint. -- Dependencies and blockers. -- Existing estimates if available. - -If calendar data is connected, account for PTO, holidays, on-call, and known meetings. - -### 2. Set Sprint Goal - -Write one clear sentence describing what success looks like. If the proposed backlog cannot support one coherent goal, call out that the sprint is unfocused. - -### 3. Estimate Capacity - -Calculate planned capacity and leave buffer: -- Prefer planning to 70-80 percent of realistic capacity. -- Account for interrupts and operational work. -- Make carryover explicit rather than hiding it in new work. - -### 4. Scope Backlog - -Group items: -- P0: must ship for sprint success. -- P1: should ship if capacity holds. -- P2: stretch or cutline items. - -Every item needs an owner, estimate, dependency status, and acceptance criteria or definition of done. - -### 5. Produce Sprint Plan - -Return: -- Sprint title, dates, team, and sprint goal. -- Capacity table by person. -- Sprint backlog table: priority, item, estimate, owner, dependencies. -- Planned capacity versus sprint load. -- Risks and mitigations. -- Definition of Done. -- Key dates: start, midpoint, demo, retro. - -## Rules - -- Push back on overcommitment. -- Identify what gets cut if estimates grow. -- Do not recommit carryover without understanding why it carried over. -- Keep the plan useful to engineers, not just stakeholders. diff --git a/skills/sprint-planning/agents/openai.yaml b/skills/sprint-planning/agents/openai.yaml deleted file mode 100644 index 5b89aeb1..00000000 --- a/skills/sprint-planning/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Sprint Planning" - short_description: "Plan a sprint by scoping work, estimating capacity, setting goals, and drafting a sprint plan. Use when kicking off..." - brand_color: "#4F46E5" - default_prompt: "Use $sprint-planning with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/sprint-planning/productize.json b/skills/sprint-planning/productize.json deleted file mode 100644 index 3f851bbb..00000000 --- a/skills/sprint-planning/productize.json +++ /dev/null @@ -1,48 +0,0 @@ -{ - "title": "Sprint Planning", - "category": "Delivery", - "tags": [ - "sprint", - "capacity", - "backlog", - "prioritization", - "risks", - "delivery", - "sprint-planning", - "planning", - "project", - "management", - "plan", - "scoping", - "work", - "estimating" - ], - "lifecycle": "Plan", - "use_when": "Plan a sprint by scoping work, estimating capacity, setting goals, and drafting a sprint plan. Use when kicking off a sprint, sizing a backlog against availability, deciding P0 versus stretch, or handling carryover.", - "do_not_use_when": "Do not use Sprint Planning when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Sprint Planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "sprint-planning", - "sprint", - "planning", - "project", - "management", - "plan", - "scoping", - "work", - "delivery", - "estimating" - ], - "framework_fit": "Sprint Planning fits Delivery work in the Plan lifecycle when the user needs Sprint Planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Sprint Planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Sprint Planning as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Sprint Planning when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $sprint-planning to turn this sprint context into a decision-ready Sprint Planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Sprint Planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/sql-queries/SKILL.md b/skills/sql-queries/SKILL.md deleted file mode 100644 index 62a5f734..00000000 --- a/skills/sql-queries/SKILL.md +++ /dev/null @@ -1,384 +0,0 @@ ---- -name: sql-queries -description: >- - Write correct, performant SQL across major data warehouse dialects including Snowflake, - BigQuery, Databricks, PostgreSQL, and Redshift. Use when writing queries, optimizing slow SQL, - translating dialects, or building analytical queries with CTEs, windows, and aggregations. ---- - - - -# SQL Queries - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `sql-queries` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: SQL Queries analytics diagnosis with metric readout, caveats, decision, and next instrumented step - -Helper skill for writing correct, performant, readable SQL across major warehouse dialects. - -## Invocation - -This is primarily a support skill for `analyze`, `explore-data`, `metrics-review`, `create-viz`, `build-dashboard`, and `data-context-extractor`. Use it explicitly when dialect-specific SQL guidance is needed. - -## Core Rules - -- Identify the SQL dialect before writing syntax-sensitive queries. -- Prefer readable CTEs for multi-step analysis. -- Qualify columns with table aliases in joins. -- Protect division with `NULLIF(denominator, 0)` or dialect-safe functions. -- Avoid `SELECT *` in analytical warehouse queries unless profiling a small table. -- Filter partition/date columns early on large tables. -- State assumptions about grain, filters, timezone, and deduplication. -- Include validation queries for non-trivial analysis. - -## Dialect Reference - -### PostgreSQL, Aurora, RDS, Supabase, Neon - -Date/time: - -```sql -CURRENT_DATE, CURRENT_TIMESTAMP, NOW() -date_column + INTERVAL '7 days' -date_column - INTERVAL '1 month' -DATE_TRUNC('month', created_at) -EXTRACT(YEAR FROM created_at) -EXTRACT(DOW FROM created_at) -- 0=Sunday -TO_CHAR(created_at, 'YYYY-MM-DD') -``` - -Strings, arrays, JSON: - -```sql -first_name || ' ' || last_name -CONCAT(first_name, ' ', last_name) -column ILIKE '%pattern%' -column ~ '^regex_pattern$' -SPLIT_PART(str, delimiter, position) -data->>'key' -data->'nested'->'key' -data#>>'{path,to,key}' -ARRAY_AGG(column) -array_column @> ARRAY['value'] -``` - -Performance: -- Use `EXPLAIN ANALYZE`. -- Index frequently filtered or joined columns. -- Consider partial indexes for common filters. -- Use `EXISTS` over correlated `IN` when appropriate. - -### Snowflake - -Date/time: - -```sql -CURRENT_DATE(), CURRENT_TIMESTAMP(), SYSDATE() -DATEADD(day, 7, date_column) -DATEDIFF(day, start_date, end_date) -DATE_TRUNC('month', created_at) -YEAR(created_at), MONTH(created_at), DAY(created_at) -DAYOFWEEK(created_at) -TO_CHAR(created_at, 'YYYY-MM-DD') -``` - -Semi-structured data: - -```sql -column ILIKE '%pattern%' -REGEXP_LIKE(column, 'pattern') -data:customer:name::STRING -data:items[0]:price::NUMBER - -SELECT - t.id, - item.value:name::STRING AS item_name, - item.value:qty::NUMBER AS quantity -FROM my_table t, -LATERAL FLATTEN(input => t.data:items) item; -``` - -Performance: -- Use clustering keys on large tables. -- Filter on clustering columns for pruning. -- Use appropriate warehouse size. -- Use `RESULT_SCAN(LAST_QUERY_ID())` to avoid rerunning expensive queries. -- Use transient tables for staging. - -### BigQuery - -Date/time: - -```sql -CURRENT_DATE(), CURRENT_TIMESTAMP() -DATE_ADD(date_column, INTERVAL 7 DAY) -DATE_SUB(date_column, INTERVAL 1 MONTH) -DATE_DIFF(end_date, start_date, DAY) -TIMESTAMP_DIFF(end_ts, start_ts, HOUR) -DATE_TRUNC(created_at, MONTH) -TIMESTAMP_TRUNC(created_at, HOUR) -EXTRACT(YEAR FROM created_at) -EXTRACT(DAYOFWEEK FROM created_at) -- 1=Sunday -FORMAT_DATE('%Y-%m-%d', date_column) -``` - -Strings, arrays, structs: - -```sql -LOWER(column) LIKE '%pattern%' -REGEXP_CONTAINS(column, r'pattern') -REGEXP_EXTRACT(column, r'pattern') -SPLIT(str, delimiter) -ARRAY_TO_STRING(array, delimiter) -ARRAY_AGG(column) -UNNEST(array_column) -ARRAY_LENGTH(array_column) -value IN UNNEST(array_column) -struct_column.field_name -``` - -Performance: -- Always filter partition columns to reduce bytes scanned. -- Use clustering for frequent filters within partitions. -- Use `APPROX_COUNT_DISTINCT()` for large-cardinality estimates. -- Avoid `SELECT *` because billing is per byte scanned. -- Use dry runs for expensive queries. - -### Redshift - -Date/time: - -```sql -CURRENT_DATE, GETDATE(), SYSDATE -DATEADD(day, 7, date_column) -DATEDIFF(day, start_date, end_date) -DATE_TRUNC('month', created_at) -EXTRACT(YEAR FROM created_at) -DATE_PART('dow', created_at) -``` - -Strings: - -```sql -column ILIKE '%pattern%' -REGEXP_INSTR(column, 'pattern') > 0 -SPLIT_PART(str, delimiter, position) -LISTAGG(column, ', ') WITHIN GROUP (ORDER BY column) -``` - -Performance: -- Choose DISTKEY for collocated joins. -- Choose SORTKEY for frequent filters. -- Use `EXPLAIN` to inspect plans. -- Watch for cross-node movement. -- Run `ANALYZE` and `VACUUM` regularly. - -### Databricks SQL - -Date/time: - -```sql -CURRENT_DATE(), CURRENT_TIMESTAMP() -DATE_ADD(date_column, 7) -DATEDIFF(end_date, start_date) -ADD_MONTHS(date_column, 1) -DATE_TRUNC('MONTH', created_at) -TRUNC(date_column, 'MM') -YEAR(created_at), MONTH(created_at) -DAYOFWEEK(created_at) -``` - -Delta Lake: - -```sql -SELECT * FROM my_table TIMESTAMP AS OF '2024-01-15'; -SELECT * FROM my_table VERSION AS OF 42; -DESCRIBE HISTORY my_table; - -MERGE INTO target USING source -ON target.id = source.id -WHEN MATCHED THEN UPDATE SET * -WHEN NOT MATCHED THEN INSERT *; -``` - -Performance: -- Use Delta `OPTIMIZE` and `ZORDER`. -- Use Photon for compute-heavy workloads when available. -- Cache frequently accessed datasets. -- Partition by low-cardinality date columns. - -## Common Patterns - -### Window Functions - -```sql -ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) -RANK() OVER (PARTITION BY category ORDER BY revenue DESC) -DENSE_RANK() OVER (ORDER BY score DESC) - -SUM(revenue) OVER ( - ORDER BY date_col ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW -) AS running_total - -AVG(revenue) OVER ( - ORDER BY date_col ROWS BETWEEN 6 PRECEDING AND CURRENT ROW -) AS moving_avg_7d - -LAG(value, 1) OVER (PARTITION BY entity ORDER BY date_col) AS prev_value -LEAD(value, 1) OVER (PARTITION BY entity ORDER BY date_col) AS next_value - -revenue / NULLIF(SUM(revenue) OVER (), 0) AS pct_of_total -revenue / NULLIF(SUM(revenue) OVER (PARTITION BY category), 0) AS pct_of_category -``` - -### CTE Structure - -```sql -WITH -base_users AS ( - SELECT user_id, created_at, plan_type - FROM users - WHERE created_at >= DATE '2024-01-01' - AND status = 'active' -), -user_metrics AS ( - SELECT - u.user_id, - u.plan_type, - COUNT(DISTINCT e.session_id) AS session_count, - SUM(e.revenue) AS total_revenue - FROM base_users u - LEFT JOIN events e ON u.user_id = e.user_id - GROUP BY u.user_id, u.plan_type -), -summary AS ( - SELECT - plan_type, - COUNT(*) AS user_count, - AVG(session_count) AS avg_sessions, - SUM(total_revenue) AS total_revenue - FROM user_metrics - GROUP BY plan_type -) -SELECT * -FROM summary -ORDER BY total_revenue DESC; -``` - -### Funnel Analysis - -```sql -WITH funnel AS ( - SELECT - user_id, - MAX(CASE WHEN event = 'page_view' THEN 1 ELSE 0 END) AS step_1_view, - MAX(CASE WHEN event = 'signup_start' THEN 1 ELSE 0 END) AS step_2_start, - MAX(CASE WHEN event = 'signup_complete' THEN 1 ELSE 0 END) AS step_3_complete, - MAX(CASE WHEN event = 'first_purchase' THEN 1 ELSE 0 END) AS step_4_purchase - FROM events - WHERE event_date >= CURRENT_DATE - INTERVAL '30 days' - GROUP BY user_id -) -SELECT - COUNT(*) AS total_users, - SUM(step_1_view) AS viewed, - SUM(step_2_start) AS started_signup, - SUM(step_3_complete) AS completed_signup, - SUM(step_4_purchase) AS purchased, - ROUND(100.0 * SUM(step_2_start) / NULLIF(SUM(step_1_view), 0), 1) AS view_to_start_pct, - ROUND(100.0 * SUM(step_3_complete) / NULLIF(SUM(step_2_start), 0), 1) AS start_to_complete_pct, - ROUND(100.0 * SUM(step_4_purchase) / NULLIF(SUM(step_3_complete), 0), 1) AS complete_to_purchase_pct -FROM funnel; -``` - -### Deduplication - -```sql -WITH ranked AS ( - SELECT - *, - ROW_NUMBER() OVER ( - PARTITION BY entity_id - ORDER BY updated_at DESC - ) AS rn - FROM source_table -) -SELECT * -FROM ranked -WHERE rn = 1; -``` - -## Debugging - -When a query fails: -1. Syntax: check dialect-specific syntax. -2. Column not found: verify schema, spelling, and case sensitivity. -3. Type mismatch: cast explicitly. -4. Division by zero: use `NULLIF` or safe division. -5. Ambiguous column: qualify with table aliases. -6. Grouping error: ensure non-aggregated columns are grouped. -7. Wrong result shape: check grain, join cardinality, and deduplication. - -## Validation Queries - -For analytical queries, add checks: -- Input row counts by source table. -- Date range coverage. -- Distinct key counts before and after joins. -- Duplicate key checks. -- Null rates for join keys and metric columns. -- Aggregate reconciliation against known totals. diff --git a/skills/sql-queries/SKILL.md.tmpl b/skills/sql-queries/SKILL.md.tmpl deleted file mode 100644 index 5705b190..00000000 --- a/skills/sql-queries/SKILL.md.tmpl +++ /dev/null @@ -1,325 +0,0 @@ ---- -name: sql-queries -description: >- - Write correct, performant SQL across major data warehouse dialects including Snowflake, - BigQuery, Databricks, PostgreSQL, and Redshift. Use when writing queries, optimizing slow SQL, - translating dialects, or building analytical queries with CTEs, windows, and aggregations. ---- -# SQL Queries - -{{PRODUCTIZE_PREAMBLE}} - -Helper skill for writing correct, performant, readable SQL across major warehouse dialects. - -## Invocation - -This is primarily a support skill for `analyze`, `explore-data`, `metrics-review`, `create-viz`, `build-dashboard`, and `data-context-extractor`. Use it explicitly when dialect-specific SQL guidance is needed. - -## Core Rules - -- Identify the SQL dialect before writing syntax-sensitive queries. -- Prefer readable CTEs for multi-step analysis. -- Qualify columns with table aliases in joins. -- Protect division with `NULLIF(denominator, 0)` or dialect-safe functions. -- Avoid `SELECT *` in analytical warehouse queries unless profiling a small table. -- Filter partition/date columns early on large tables. -- State assumptions about grain, filters, timezone, and deduplication. -- Include validation queries for non-trivial analysis. - -## Dialect Reference - -### PostgreSQL, Aurora, RDS, Supabase, Neon - -Date/time: - -```sql -CURRENT_DATE, CURRENT_TIMESTAMP, NOW() -date_column + INTERVAL '7 days' -date_column - INTERVAL '1 month' -DATE_TRUNC('month', created_at) -EXTRACT(YEAR FROM created_at) -EXTRACT(DOW FROM created_at) -- 0=Sunday -TO_CHAR(created_at, 'YYYY-MM-DD') -``` - -Strings, arrays, JSON: - -```sql -first_name || ' ' || last_name -CONCAT(first_name, ' ', last_name) -column ILIKE '%pattern%' -column ~ '^regex_pattern$' -SPLIT_PART(str, delimiter, position) -data->>'key' -data->'nested'->'key' -data#>>'{path,to,key}' -ARRAY_AGG(column) -array_column @> ARRAY['value'] -``` - -Performance: -- Use `EXPLAIN ANALYZE`. -- Index frequently filtered or joined columns. -- Consider partial indexes for common filters. -- Use `EXISTS` over correlated `IN` when appropriate. - -### Snowflake - -Date/time: - -```sql -CURRENT_DATE(), CURRENT_TIMESTAMP(), SYSDATE() -DATEADD(day, 7, date_column) -DATEDIFF(day, start_date, end_date) -DATE_TRUNC('month', created_at) -YEAR(created_at), MONTH(created_at), DAY(created_at) -DAYOFWEEK(created_at) -TO_CHAR(created_at, 'YYYY-MM-DD') -``` - -Semi-structured data: - -```sql -column ILIKE '%pattern%' -REGEXP_LIKE(column, 'pattern') -data:customer:name::STRING -data:items[0]:price::NUMBER - -SELECT - t.id, - item.value:name::STRING AS item_name, - item.value:qty::NUMBER AS quantity -FROM my_table t, -LATERAL FLATTEN(input => t.data:items) item; -``` - -Performance: -- Use clustering keys on large tables. -- Filter on clustering columns for pruning. -- Use appropriate warehouse size. -- Use `RESULT_SCAN(LAST_QUERY_ID())` to avoid rerunning expensive queries. -- Use transient tables for staging. - -### BigQuery - -Date/time: - -```sql -CURRENT_DATE(), CURRENT_TIMESTAMP() -DATE_ADD(date_column, INTERVAL 7 DAY) -DATE_SUB(date_column, INTERVAL 1 MONTH) -DATE_DIFF(end_date, start_date, DAY) -TIMESTAMP_DIFF(end_ts, start_ts, HOUR) -DATE_TRUNC(created_at, MONTH) -TIMESTAMP_TRUNC(created_at, HOUR) -EXTRACT(YEAR FROM created_at) -EXTRACT(DAYOFWEEK FROM created_at) -- 1=Sunday -FORMAT_DATE('%Y-%m-%d', date_column) -``` - -Strings, arrays, structs: - -```sql -LOWER(column) LIKE '%pattern%' -REGEXP_CONTAINS(column, r'pattern') -REGEXP_EXTRACT(column, r'pattern') -SPLIT(str, delimiter) -ARRAY_TO_STRING(array, delimiter) -ARRAY_AGG(column) -UNNEST(array_column) -ARRAY_LENGTH(array_column) -value IN UNNEST(array_column) -struct_column.field_name -``` - -Performance: -- Always filter partition columns to reduce bytes scanned. -- Use clustering for frequent filters within partitions. -- Use `APPROX_COUNT_DISTINCT()` for large-cardinality estimates. -- Avoid `SELECT *` because billing is per byte scanned. -- Use dry runs for expensive queries. - -### Redshift - -Date/time: - -```sql -CURRENT_DATE, GETDATE(), SYSDATE -DATEADD(day, 7, date_column) -DATEDIFF(day, start_date, end_date) -DATE_TRUNC('month', created_at) -EXTRACT(YEAR FROM created_at) -DATE_PART('dow', created_at) -``` - -Strings: - -```sql -column ILIKE '%pattern%' -REGEXP_INSTR(column, 'pattern') > 0 -SPLIT_PART(str, delimiter, position) -LISTAGG(column, ', ') WITHIN GROUP (ORDER BY column) -``` - -Performance: -- Choose DISTKEY for collocated joins. -- Choose SORTKEY for frequent filters. -- Use `EXPLAIN` to inspect plans. -- Watch for cross-node movement. -- Run `ANALYZE` and `VACUUM` regularly. - -### Databricks SQL - -Date/time: - -```sql -CURRENT_DATE(), CURRENT_TIMESTAMP() -DATE_ADD(date_column, 7) -DATEDIFF(end_date, start_date) -ADD_MONTHS(date_column, 1) -DATE_TRUNC('MONTH', created_at) -TRUNC(date_column, 'MM') -YEAR(created_at), MONTH(created_at) -DAYOFWEEK(created_at) -``` - -Delta Lake: - -```sql -SELECT * FROM my_table TIMESTAMP AS OF '2024-01-15'; -SELECT * FROM my_table VERSION AS OF 42; -DESCRIBE HISTORY my_table; - -MERGE INTO target USING source -ON target.id = source.id -WHEN MATCHED THEN UPDATE SET * -WHEN NOT MATCHED THEN INSERT *; -``` - -Performance: -- Use Delta `OPTIMIZE` and `ZORDER`. -- Use Photon for compute-heavy workloads when available. -- Cache frequently accessed datasets. -- Partition by low-cardinality date columns. - -## Common Patterns - -### Window Functions - -```sql -ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) -RANK() OVER (PARTITION BY category ORDER BY revenue DESC) -DENSE_RANK() OVER (ORDER BY score DESC) - -SUM(revenue) OVER ( - ORDER BY date_col ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW -) AS running_total - -AVG(revenue) OVER ( - ORDER BY date_col ROWS BETWEEN 6 PRECEDING AND CURRENT ROW -) AS moving_avg_7d - -LAG(value, 1) OVER (PARTITION BY entity ORDER BY date_col) AS prev_value -LEAD(value, 1) OVER (PARTITION BY entity ORDER BY date_col) AS next_value - -revenue / NULLIF(SUM(revenue) OVER (), 0) AS pct_of_total -revenue / NULLIF(SUM(revenue) OVER (PARTITION BY category), 0) AS pct_of_category -``` - -### CTE Structure - -```sql -WITH -base_users AS ( - SELECT user_id, created_at, plan_type - FROM users - WHERE created_at >= DATE '2024-01-01' - AND status = 'active' -), -user_metrics AS ( - SELECT - u.user_id, - u.plan_type, - COUNT(DISTINCT e.session_id) AS session_count, - SUM(e.revenue) AS total_revenue - FROM base_users u - LEFT JOIN events e ON u.user_id = e.user_id - GROUP BY u.user_id, u.plan_type -), -summary AS ( - SELECT - plan_type, - COUNT(*) AS user_count, - AVG(session_count) AS avg_sessions, - SUM(total_revenue) AS total_revenue - FROM user_metrics - GROUP BY plan_type -) -SELECT * -FROM summary -ORDER BY total_revenue DESC; -``` - -### Funnel Analysis - -```sql -WITH funnel AS ( - SELECT - user_id, - MAX(CASE WHEN event = 'page_view' THEN 1 ELSE 0 END) AS step_1_view, - MAX(CASE WHEN event = 'signup_start' THEN 1 ELSE 0 END) AS step_2_start, - MAX(CASE WHEN event = 'signup_complete' THEN 1 ELSE 0 END) AS step_3_complete, - MAX(CASE WHEN event = 'first_purchase' THEN 1 ELSE 0 END) AS step_4_purchase - FROM events - WHERE event_date >= CURRENT_DATE - INTERVAL '30 days' - GROUP BY user_id -) -SELECT - COUNT(*) AS total_users, - SUM(step_1_view) AS viewed, - SUM(step_2_start) AS started_signup, - SUM(step_3_complete) AS completed_signup, - SUM(step_4_purchase) AS purchased, - ROUND(100.0 * SUM(step_2_start) / NULLIF(SUM(step_1_view), 0), 1) AS view_to_start_pct, - ROUND(100.0 * SUM(step_3_complete) / NULLIF(SUM(step_2_start), 0), 1) AS start_to_complete_pct, - ROUND(100.0 * SUM(step_4_purchase) / NULLIF(SUM(step_3_complete), 0), 1) AS complete_to_purchase_pct -FROM funnel; -``` - -### Deduplication - -```sql -WITH ranked AS ( - SELECT - *, - ROW_NUMBER() OVER ( - PARTITION BY entity_id - ORDER BY updated_at DESC - ) AS rn - FROM source_table -) -SELECT * -FROM ranked -WHERE rn = 1; -``` - -## Debugging - -When a query fails: -1. Syntax: check dialect-specific syntax. -2. Column not found: verify schema, spelling, and case sensitivity. -3. Type mismatch: cast explicitly. -4. Division by zero: use `NULLIF` or safe division. -5. Ambiguous column: qualify with table aliases. -6. Grouping error: ensure non-aggregated columns are grouped. -7. Wrong result shape: check grain, join cardinality, and deduplication. - -## Validation Queries - -For analytical queries, add checks: -- Input row counts by source table. -- Date range coverage. -- Distinct key counts before and after joins. -- Duplicate key checks. -- Null rates for join keys and metric columns. -- Aggregate reconciliation against known totals. diff --git a/skills/sql-queries/agents/openai.yaml b/skills/sql-queries/agents/openai.yaml deleted file mode 100644 index 74904d80..00000000 --- a/skills/sql-queries/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "SQL Queries" - short_description: "Write correct, performant SQL across major data warehouse dialects including Snowflake, BigQuery, Databricks,..." - brand_color: "#0F766E" - default_prompt: "Use $sql-queries with my product context." - -policy: - allow_implicit_invocation: false diff --git a/skills/sql-queries/productize.json b/skills/sql-queries/productize.json deleted file mode 100644 index ef3be397..00000000 --- a/skills/sql-queries/productize.json +++ /dev/null @@ -1,49 +0,0 @@ -{ - "title": "SQL Queries", - "category": "Analytics", - "allow_implicit_invocation": false, - "tags": [ - "sql", - "warehouse", - "dialects", - "query-optimization", - "ctes", - "window-functions", - "sql-queries", - "queries", - "data", - "reporting", - "write", - "correct", - "performant", - "analytics" - ], - "lifecycle": "Measure", - "use_when": "Write correct, performant SQL across major data warehouse dialects including Snowflake, BigQuery, Databricks, PostgreSQL, and Redshift. Use when writing queries, optimizing slow SQL, translating dialects, or building analytical queries with CTEs, windows, and aggregations.", - "do_not_use_when": "Do not use SQL Queries when the request is mainly early ideation, qualitative research, or roadmap writing without metrics; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "SQL Queries analytics diagnosis with metric readout, caveats, decision, and next instrumented step", - "routing_signals": [ - "sql-queries", - "sql", - "queries", - "data", - "reporting", - "write", - "correct", - "performant", - "analytics", - "across" - ], - "framework_fit": "SQL Queries fits Analytics work in the Measure lifecycle when the user needs SQL Queries analytics diagnosis with metric readout, caveats, decision, and next instrumented step and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces SQL Queries analytics diagnosis with metric readout, caveats, decision, and next instrumented step without tying recommendations to the user's Measure stage, evidence, and decision pressure.", - "Treats SQL Queries as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from SQL Queries when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $sql-queries to turn this sql context into a decision-ready SQL Queries analytics diagnosis with metric readout, caveats, decision, and next instrumented step.", - "expected_artifact": "SQL Queries analytics diagnosis with metric readout, caveats, decision, and next instrumented step" - } - ] -} diff --git a/skills/sql-query-from-requirements-and-data-tables/SKILL.md b/skills/sql-query-from-requirements-and-data-tables/SKILL.md deleted file mode 100644 index 15cc705e..00000000 --- a/skills/sql-query-from-requirements-and-data-tables/SKILL.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -name: sql-query-from-requirements-and-data-tables -description: >- - SQL query from requirements and data tables. Use when the user needs a product workflow for - business analysis related to sql query from requirements and data tables. Trigger terms: pm, - sql, analytics, data, business-analysis. ---- - - - -# SQL query from requirements and data tables - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `sql-query-from-requirements-and-data-tables` -- **Lifecycle**: Design -- **Category**: Analytics -- **Primary artifact**: SQL query from requirements and data tables UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **SQL query from requirements and data tables**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DATA_TABLES_OVERVIEW}} -- {{QUERY_CRAFTING_REQUIREMENTS}} - - -GOAL -Produce a correct, performant, and maintainable SQL query from `DATA_TABLES_OVERVIEW` and `QUERY_CRAFTING_REQUIREMENTS`. -Success metric: -- SQL satisfies requirements and uses valid joins/filters/aggregations. -- Query is optimized for readability and execution efficiency. -- Major logic choices and assumptions are clearly explained. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required SQL design steps: - - relevant table joins, - - filter conditions, - - aggregations/calculations, - - subqueries/CTEs where helpful. -- Prefer explicit selected columns (avoid `SELECT *` unless explicitly required). -- Use meaningful aliases and readable formatting. -- Add concise inline comments only for non-obvious logic. -- Include assumptions when schema or requirements are ambiguous. -- If requirements are under-specified, produce best-effort SQL and state what data/constraints would finalize it. -- Default policy for ambiguities (apply unless `QUERY_CRAFTING_REQUIREMENTS` explicitly overrides): - - **Top-5 rule:** return exactly 5 rows per month using `ROW_NUMBER()` with deterministic tie-break (`ORDER BY net_revenue_usd DESC, category ASC`). - - **Multi-category revenue attribution:** allocate order revenue proportionally by category share of item extended value (`quantity * unit_price`) within each order; do not attribute full order revenue to every category. - - **Payment-attempt attribution by category:** attribute payment attempts/failures to each category touched by an order (order-category level attribution), and explicitly disclose that summed category-level counts can exceed overall totals. - - **Payment time scope:** when reporting period filters are defined for orders, filter payment attempts to the same period using `payments.attempted_at` unless explicitly instructed otherwise. -- SQL must be executable with standard ASCII SQL syntax: - - Use `'single quotes'` for string literals. - - Use `--` for line comments. - - Do not use typographic quotes/dashes or other smart punctuation. -- Keep explanation plain text (no unusual control characters, copy artifacts, or decorative bullets). -- If metrics are attributed to multiple categories (for multi-category orders), explicitly state that totals across categories may exceed overall order/payment totals. - -FORMAT -Return exactly this structure: - - --- SQL query with formatting and comments - - -- Join strategy and why each join type is used -- Filter logic and business-rule mapping -- Aggregations/calculations rationale -- Performance considerations (indexes, cardinality, scan reduction, CTE/subquery choices) -- Assumptions and known limitations - - -FAILURE -- Missing `` or `` section. -- SQL does not match stated requirements. -- Uses `SELECT *` without explicit requirement. -- Join/filter/aggregation logic is unclear or unsupported in explanation. -- SQL contains non-ASCII smart punctuation that breaks execution (e.g., `โ€˜ โ€™`, `โ€œ โ€`, `โ€“`). -- Explanation contains copy artifacts or unreadable formatting. -- Output violates default ambiguity policies (top-5 cardinality, revenue attribution, payment attribution, or payment time scope) without explicit requirement override. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/sql-query-from-requirements-and-data-tables/SKILL.md.tmpl b/skills/sql-query-from-requirements-and-data-tables/SKILL.md.tmpl deleted file mode 100644 index ef0c2c16..00000000 --- a/skills/sql-query-from-requirements-and-data-tables/SKILL.md.tmpl +++ /dev/null @@ -1,85 +0,0 @@ ---- -name: sql-query-from-requirements-and-data-tables -description: >- - SQL query from requirements and data tables. Use when the user needs a product workflow for - business analysis related to sql query from requirements and data tables. Trigger terms: pm, - sql, analytics, data, business-analysis. ---- -# SQL query from requirements and data tables - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **SQL query from requirements and data tables**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DATA_TABLES_OVERVIEW}} -- {{QUERY_CRAFTING_REQUIREMENTS}} - - -GOAL -Produce a correct, performant, and maintainable SQL query from `DATA_TABLES_OVERVIEW` and `QUERY_CRAFTING_REQUIREMENTS`. -Success metric: -- SQL satisfies requirements and uses valid joins/filters/aggregations. -- Query is optimized for readability and execution efficiency. -- Major logic choices and assumptions are clearly explained. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required SQL design steps: - - relevant table joins, - - filter conditions, - - aggregations/calculations, - - subqueries/CTEs where helpful. -- Prefer explicit selected columns (avoid `SELECT *` unless explicitly required). -- Use meaningful aliases and readable formatting. -- Add concise inline comments only for non-obvious logic. -- Include assumptions when schema or requirements are ambiguous. -- If requirements are under-specified, produce best-effort SQL and state what data/constraints would finalize it. -- Default policy for ambiguities (apply unless `QUERY_CRAFTING_REQUIREMENTS` explicitly overrides): - - **Top-5 rule:** return exactly 5 rows per month using `ROW_NUMBER()` with deterministic tie-break (`ORDER BY net_revenue_usd DESC, category ASC`). - - **Multi-category revenue attribution:** allocate order revenue proportionally by category share of item extended value (`quantity * unit_price`) within each order; do not attribute full order revenue to every category. - - **Payment-attempt attribution by category:** attribute payment attempts/failures to each category touched by an order (order-category level attribution), and explicitly disclose that summed category-level counts can exceed overall totals. - - **Payment time scope:** when reporting period filters are defined for orders, filter payment attempts to the same period using `payments.attempted_at` unless explicitly instructed otherwise. -- SQL must be executable with standard ASCII SQL syntax: - - Use `'single quotes'` for string literals. - - Use `--` for line comments. - - Do not use typographic quotes/dashes or other smart punctuation. -- Keep explanation plain text (no unusual control characters, copy artifacts, or decorative bullets). -- If metrics are attributed to multiple categories (for multi-category orders), explicitly state that totals across categories may exceed overall order/payment totals. - -FORMAT -Return exactly this structure: - - --- SQL query with formatting and comments - - -- Join strategy and why each join type is used -- Filter logic and business-rule mapping -- Aggregations/calculations rationale -- Performance considerations (indexes, cardinality, scan reduction, CTE/subquery choices) -- Assumptions and known limitations - - -FAILURE -- Missing `` or `` section. -- SQL does not match stated requirements. -- Uses `SELECT *` without explicit requirement. -- Join/filter/aggregation logic is unclear or unsupported in explanation. -- SQL contains non-ASCII smart punctuation that breaks execution (e.g., `โ€˜ โ€™`, `โ€œ โ€`, `โ€“`). -- Explanation contains copy artifacts or unreadable formatting. -- Output violates default ambiguity policies (top-5 cardinality, revenue attribution, payment attribution, or payment time scope) without explicit requirement override. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/sql-query-from-requirements-and-data-tables/agents/openai.yaml b/skills/sql-query-from-requirements-and-data-tables/agents/openai.yaml deleted file mode 100644 index 85cb63ae..00000000 --- a/skills/sql-query-from-requirements-and-data-tables/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "SQL query from requirements and data tables" - short_description: "SQL query from requirements and data tables. Use when the user needs a product workflow for business analysis..." - brand_color: "#0F766E" - default_prompt: "Use $sql-query-from-requirements-and-data-tables with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/sql-query-from-requirements-and-data-tables/productize.json b/skills/sql-query-from-requirements-and-data-tables/productize.json deleted file mode 100644 index 9b5e0d6d..00000000 --- a/skills/sql-query-from-requirements-and-data-tables/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "SQL query from requirements and data tables", - "category": "Analytics", - "lifecycle": "Design", - "tags": [ - "sql-query-from-requirements-and-data-tables", - "sql", - "query", - "requirements", - "data", - "tables" - ], - "use_when": "SQL query from requirements and data tables. Use when the user needs a product workflow for business analysis related to sql query from requirements and data tables. Trigger terms: pm, sql, analytics, data, business-analysis.", - "do_not_use_when": "Do not use SQL query from requirements and data tables when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "SQL query from requirements and data tables UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "sql-query-from-requirements-and-data-tables", - "sql", - "query", - "requirements", - "data", - "tables" - ], - "framework_fit": "SQL query from requirements and data tables fits Analytics work in the Design lifecycle when the user needs SQL query from requirements and data tables UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces SQL query from requirements and data tables UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats SQL query from requirements and data tables as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from SQL query from requirements and data tables when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $sql-query-from-requirements-and-data-tables to turn this sql context into a decision-ready SQL query from requirements and data tables UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "SQL query from requirements and data tables UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/stakeholder-brief-clarification-and-problem-definition/SKILL.md b/skills/stakeholder-brief-clarification-and-problem-definition/SKILL.md deleted file mode 100644 index ee7dc850..00000000 --- a/skills/stakeholder-brief-clarification-and-problem-definition/SKILL.md +++ /dev/null @@ -1,311 +0,0 @@ ---- -name: stakeholder-brief-clarification-and-problem-definition -description: >- - Stakeholder Brief Clarification and Problem Definition. Use when the user needs a product - workflow for stakeholder management related to stakeholder brief clarification and problem - definition. Trigger terms: product-design, problem-framing, stakeholder-management, - user-research, metrics. ---- - - - -# Stakeholder Brief Clarification and Problem Definition - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `stakeholder-brief-clarification-and-problem-definition` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Stakeholder Brief Clarification and Problem Definition stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Stakeholder Brief Clarification and Problem Definition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{VAGUE_BRIEF}} -- {{STAKEHOLDER_CONTEXT}} -- {{BUSINESS_CONSTRAINTS}} -- {{USER_RESEARCH}} -- {{CURRENT_METRICS}} - - -GOAL -Produce a high-quality deliverable for: Stakeholder Brief Clarification and Problem Definition. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Transform `{{VAGUE_BRIEF}}` into a concrete, measurable problem definition using `{{STAKEHOLDER_CONTEXT}}`, `{{BUSINESS_CONSTRAINTS}}`, `{{USER_RESEARCH}}`, and `{{CURRENT_METRICS}}`. -- Decode subjective language, assumptions, implied intent, symptom vs root cause, and solution bias. -- Extract business drivers, user problems, and concrete success criteria. -- Translate vague terms into observable/measurable design criteria. -- Identify technical, timeline, budget, brand/design, and organizational constraints. -- Generate validation-oriented clarifying questions and actionable next steps. -- Keep analysis objective, evidence-based, and explicit about assumptions and unknowns. - -FORMAT -Return exactly this structure: - - - -**Subjective Terms Identified:** -[List each vague term with its contextual meaning] - -**Embedded Assumptions:** -- [Assumption 1] -- [Assumption 2] -- [Assumption 3] - -**Implied But Not Stated:** -[What the stakeholder assumes you know or will infer] - -**Root Cause vs. Symptom:** -- Stated symptom: [what stakeholder described] -- Likely root cause: [underlying issue driving the symptom] - - - -**Primary Business Driver:** -[The core business outcome this request aims to achieve] - -**Revenue/Growth Connection:** -[How this impacts company financial goals] - -**Strategic Alignment:** -[How this connects to broader company strategy or roadmap] - -**Competitive Context:** -[Market forces or competitor actions driving this] - -**Internal Stakeholder Pressures:** -[Political, reputational, or organizational dynamics] - -**Cost of Inaction:** -[What happens if this problem isn't solved] - - - -**Affected User Segments:** -- [Segment 1]: [specific pain points] -- [Segment 2]: [specific pain points] -- [Segment 3]: [specific pain points] - -**User-Reported Pain Points:** -[Direct quotes or themes from user research, support tickets, reviews] - -**Behavioral Evidence:** -[Observable user behaviors that indicate this problem exists] - -**Current Workarounds:** -[How users compensate for this problem today] - -**Impact on User Journeys:** -[Specific tasks or flows where users experience friction] - -**Severity Assessment:** -- Frequency: [how often users encounter this] -- Impact: [how much it affects user success] -- User priority: [how users would rank fixing this] - - - -**Translation of "[VAGUE_TERM_1]":** -- Criterion 1: [specific, measurable attribute] -- Criterion 2: [specific, measurable attribute] -- Criterion 3: [specific, measurable attribute] - -**Translation of "[VAGUE_TERM_2]":** -- Criterion 1: [specific, measurable attribute] -- Criterion 2: [specific, measurable attribute] -- Criterion 3: [specific, measurable attribute] - -**Observable Design Characteristics:** -[Specific visual, interaction, or structural attributes that would demonstrate the vague term has been achieved] - -**User-Facing Improvements:** -[Concrete changes users would notice and value] - - - -**Primary Success Metric:** -- Metric: [specific measurement] -- Current baseline: [X] -- Target: [Y] -- Timeline: [when to measure] -- Collection method: [how to measure] - -**Secondary Metrics:** -1. [Metric]: [baseline] โ†’ [target] by [date] -2. [Metric]: [baseline] โ†’ [target] by [date] -3. [Metric]: [baseline] โ†’ [target] by [date] - -**Leading Indicators:** -- [Early signal 1] -- [Early signal 2] -- [Early signal 3] - -**Qualitative Success Signals:** -- [User feedback theme or sentiment shift] -- [Stakeholder observation or report] -- [Support ticket reduction in specific category] - -**Risks to Monitor:** -[Potential negative metrics that could indicate unintended consequences] - - - - -- [Constraint 1 with impact on design options] -- [Constraint 2 with impact on design options] -- [Constraint 3 with impact on design options] - - - -- Hard deadline: [date and reason] -- Resource availability: [when team is available] -- Dependencies: [what must happen first] - - - -- Development capacity: [hours or sprints available] -- Research budget: [ability to validate with users] -- Third-party costs: [tools or services needed] - - - -- Design system: [existing components and patterns to leverage] -- Accessibility: [WCAG level required, existing debt] -- Brand guidelines: [visual identity rules that apply] - - - -- Approval process: [who must sign off, when] -- Cross-team dependencies: [coordination needed] -- Political considerations: [stakeholder dynamics] - - - - -**Problem Statement:** -We need to [specific design action] for [specific user segment] so that [specific user outcome] and [specific business outcome], as measured by [primary metric] improving from [baseline] to [target] by [date], while considering [key constraints]. - -**In Plain Language:** -[Restate the problem statement in conversational terms that any stakeholder can understand] - -**Scope Boundaries:** -- In scope: [what this problem statement includes] -- Out of scope: [what this explicitly does not include] -- Future consideration: [what might be addressed later] - - - -**Business Outcome Validation:** -1. What would represent a home-run outcome for this initiative in 6 months? -2. If we could only improve one business metric, which would matter most? -3. What would cause you to consider this effort a failure, even if users liked it? - -**User Need Validation:** -4. Which user segment would benefit most from solving this problem? -5. How do we know users actually experience this as a problem vs. our assumption? -6. What would users give up or trade off to get this improvement? - -**Scope and Priority Validation:** -7. If we had to cut scope by 50%, what's the core of this request we must keep? -8. What's more important: shipping by [date] or achieving [specific outcome]? -9. How does this compare in priority to [other initiative on roadmap]? - -**Constraints Validation:** -10. What technical limitations should we absolutely not try to work around? -11. Are there brand or design standards we could flex if it meant better user outcomes? -12. What budget or timeline assumptions should we validate before proceeding? - -**Success Criteria Validation:** -13. How will we know if we've succeeded in 3 months? 6 months? 12 months? -14. What user feedback or behavior would make you confident we solved this? -15. What business metrics matter more than hitting the launch date? - - - -1. **Validate assumptions:** [Specific research or conversations needed to confirm problem understanding] -2. **Baseline metrics:** [Establish current measurements for success criteria] -3. **Exploratory design:** [Create lightweight concepts to test problem framing] -4. **Stakeholder alignment:** [Schedule review of refined problem statement with key stakeholders] -5. **Technical feasibility:** [Partner with engineering to validate constraints and opportunities] -6. **User validation:** [Test problem statement against actual user pain points through interviews or surveys] -7. **Prioritization:** [Compare this problem statement against other roadmap items] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Problem statement is not measurable (missing baseline/target/date/constraints). -- Clarifying questions are not actionable or do not address business, user, scope, constraints, and success validation. -- Metrics and constraints are generic or not traceable to the provided inputs. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-brief-clarification-and-problem-definition/SKILL.md.tmpl b/skills/stakeholder-brief-clarification-and-problem-definition/SKILL.md.tmpl deleted file mode 100644 index de738b1f..00000000 --- a/skills/stakeholder-brief-clarification-and-problem-definition/SKILL.md.tmpl +++ /dev/null @@ -1,252 +0,0 @@ ---- -name: stakeholder-brief-clarification-and-problem-definition -description: >- - Stakeholder Brief Clarification and Problem Definition. Use when the user needs a product - workflow for stakeholder management related to stakeholder brief clarification and problem - definition. Trigger terms: product-design, problem-framing, stakeholder-management, - user-research, metrics. ---- -# Stakeholder Brief Clarification and Problem Definition - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Stakeholder Brief Clarification and Problem Definition**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{VAGUE_BRIEF}} -- {{STAKEHOLDER_CONTEXT}} -- {{BUSINESS_CONSTRAINTS}} -- {{USER_RESEARCH}} -- {{CURRENT_METRICS}} - - -GOAL -Produce a high-quality deliverable for: Stakeholder Brief Clarification and Problem Definition. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Transform `{{VAGUE_BRIEF}}` into a concrete, measurable problem definition using `{{STAKEHOLDER_CONTEXT}}`, `{{BUSINESS_CONSTRAINTS}}`, `{{USER_RESEARCH}}`, and `{{CURRENT_METRICS}}`. -- Decode subjective language, assumptions, implied intent, symptom vs root cause, and solution bias. -- Extract business drivers, user problems, and concrete success criteria. -- Translate vague terms into observable/measurable design criteria. -- Identify technical, timeline, budget, brand/design, and organizational constraints. -- Generate validation-oriented clarifying questions and actionable next steps. -- Keep analysis objective, evidence-based, and explicit about assumptions and unknowns. - -FORMAT -Return exactly this structure: - - - -**Subjective Terms Identified:** -[List each vague term with its contextual meaning] - -**Embedded Assumptions:** -- [Assumption 1] -- [Assumption 2] -- [Assumption 3] - -**Implied But Not Stated:** -[What the stakeholder assumes you know or will infer] - -**Root Cause vs. Symptom:** -- Stated symptom: [what stakeholder described] -- Likely root cause: [underlying issue driving the symptom] - - - -**Primary Business Driver:** -[The core business outcome this request aims to achieve] - -**Revenue/Growth Connection:** -[How this impacts company financial goals] - -**Strategic Alignment:** -[How this connects to broader company strategy or roadmap] - -**Competitive Context:** -[Market forces or competitor actions driving this] - -**Internal Stakeholder Pressures:** -[Political, reputational, or organizational dynamics] - -**Cost of Inaction:** -[What happens if this problem isn't solved] - - - -**Affected User Segments:** -- [Segment 1]: [specific pain points] -- [Segment 2]: [specific pain points] -- [Segment 3]: [specific pain points] - -**User-Reported Pain Points:** -[Direct quotes or themes from user research, support tickets, reviews] - -**Behavioral Evidence:** -[Observable user behaviors that indicate this problem exists] - -**Current Workarounds:** -[How users compensate for this problem today] - -**Impact on User Journeys:** -[Specific tasks or flows where users experience friction] - -**Severity Assessment:** -- Frequency: [how often users encounter this] -- Impact: [how much it affects user success] -- User priority: [how users would rank fixing this] - - - -**Translation of "[VAGUE_TERM_1]":** -- Criterion 1: [specific, measurable attribute] -- Criterion 2: [specific, measurable attribute] -- Criterion 3: [specific, measurable attribute] - -**Translation of "[VAGUE_TERM_2]":** -- Criterion 1: [specific, measurable attribute] -- Criterion 2: [specific, measurable attribute] -- Criterion 3: [specific, measurable attribute] - -**Observable Design Characteristics:** -[Specific visual, interaction, or structural attributes that would demonstrate the vague term has been achieved] - -**User-Facing Improvements:** -[Concrete changes users would notice and value] - - - -**Primary Success Metric:** -- Metric: [specific measurement] -- Current baseline: [X] -- Target: [Y] -- Timeline: [when to measure] -- Collection method: [how to measure] - -**Secondary Metrics:** -1. [Metric]: [baseline] โ†’ [target] by [date] -2. [Metric]: [baseline] โ†’ [target] by [date] -3. [Metric]: [baseline] โ†’ [target] by [date] - -**Leading Indicators:** -- [Early signal 1] -- [Early signal 2] -- [Early signal 3] - -**Qualitative Success Signals:** -- [User feedback theme or sentiment shift] -- [Stakeholder observation or report] -- [Support ticket reduction in specific category] - -**Risks to Monitor:** -[Potential negative metrics that could indicate unintended consequences] - - - - -- [Constraint 1 with impact on design options] -- [Constraint 2 with impact on design options] -- [Constraint 3 with impact on design options] - - - -- Hard deadline: [date and reason] -- Resource availability: [when team is available] -- Dependencies: [what must happen first] - - - -- Development capacity: [hours or sprints available] -- Research budget: [ability to validate with users] -- Third-party costs: [tools or services needed] - - - -- Design system: [existing components and patterns to leverage] -- Accessibility: [WCAG level required, existing debt] -- Brand guidelines: [visual identity rules that apply] - - - -- Approval process: [who must sign off, when] -- Cross-team dependencies: [coordination needed] -- Political considerations: [stakeholder dynamics] - - - - -**Problem Statement:** -We need to [specific design action] for [specific user segment] so that [specific user outcome] and [specific business outcome], as measured by [primary metric] improving from [baseline] to [target] by [date], while considering [key constraints]. - -**In Plain Language:** -[Restate the problem statement in conversational terms that any stakeholder can understand] - -**Scope Boundaries:** -- In scope: [what this problem statement includes] -- Out of scope: [what this explicitly does not include] -- Future consideration: [what might be addressed later] - - - -**Business Outcome Validation:** -1. What would represent a home-run outcome for this initiative in 6 months? -2. If we could only improve one business metric, which would matter most? -3. What would cause you to consider this effort a failure, even if users liked it? - -**User Need Validation:** -4. Which user segment would benefit most from solving this problem? -5. How do we know users actually experience this as a problem vs. our assumption? -6. What would users give up or trade off to get this improvement? - -**Scope and Priority Validation:** -7. If we had to cut scope by 50%, what's the core of this request we must keep? -8. What's more important: shipping by [date] or achieving [specific outcome]? -9. How does this compare in priority to [other initiative on roadmap]? - -**Constraints Validation:** -10. What technical limitations should we absolutely not try to work around? -11. Are there brand or design standards we could flex if it meant better user outcomes? -12. What budget or timeline assumptions should we validate before proceeding? - -**Success Criteria Validation:** -13. How will we know if we've succeeded in 3 months? 6 months? 12 months? -14. What user feedback or behavior would make you confident we solved this? -15. What business metrics matter more than hitting the launch date? - - - -1. **Validate assumptions:** [Specific research or conversations needed to confirm problem understanding] -2. **Baseline metrics:** [Establish current measurements for success criteria] -3. **Exploratory design:** [Create lightweight concepts to test problem framing] -4. **Stakeholder alignment:** [Schedule review of refined problem statement with key stakeholders] -5. **Technical feasibility:** [Partner with engineering to validate constraints and opportunities] -6. **User validation:** [Test problem statement against actual user pain points through interviews or surveys] -7. **Prioritization:** [Compare this problem statement against other roadmap items] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Problem statement is not measurable (missing baseline/target/date/constraints). -- Clarifying questions are not actionable or do not address business, user, scope, constraints, and success validation. -- Metrics and constraints are generic or not traceable to the provided inputs. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-brief-clarification-and-problem-definition/agents/openai.yaml b/skills/stakeholder-brief-clarification-and-problem-definition/agents/openai.yaml deleted file mode 100644 index cc380875..00000000 --- a/skills/stakeholder-brief-clarification-and-problem-definition/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Stakeholder Brief Clarification and Problem Definition" - short_description: "Stakeholder Brief Clarification and Problem Definition. Use when the user needs a product workflow for stakeholder..." - brand_color: "#0891B2" - default_prompt: "Use $stakeholder-brief-clarification-and-problem-definition with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/stakeholder-brief-clarification-and-problem-definition/productize.json b/skills/stakeholder-brief-clarification-and-problem-definition/productize.json deleted file mode 100644 index db0034c8..00000000 --- a/skills/stakeholder-brief-clarification-and-problem-definition/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Stakeholder Brief Clarification and Problem Definition", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "stakeholder-brief-clarification-and-problem-definition", - "stakeholder", - "brief", - "clarification", - "problem", - "definition" - ], - "use_when": "Stakeholder Brief Clarification and Problem Definition. Use when the user needs a product workflow for stakeholder management related to stakeholder brief clarification and problem definition. Trigger terms: product-design, problem-framing, stakeholder-management, user-research, metrics.", - "do_not_use_when": "Do not use Stakeholder Brief Clarification and Problem Definition when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Stakeholder Brief Clarification and Problem Definition stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "stakeholder-brief-clarification-and-problem-definition", - "stakeholder", - "brief", - "clarification", - "problem", - "definition" - ], - "framework_fit": "Stakeholder Brief Clarification and Problem Definition fits Stakeholder Communication work in the Align lifecycle when the user needs Stakeholder Brief Clarification and Problem Definition stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Stakeholder Brief Clarification and Problem Definition stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Stakeholder Brief Clarification and Problem Definition as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Stakeholder Brief Clarification and Problem Definition when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $stakeholder-brief-clarification-and-problem-definition to turn this stakeholder context into a decision-ready Stakeholder Brief Clarification and Problem Definition stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Stakeholder Brief Clarification and Problem Definition stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/stakeholder-decision-making-using-toc-thinking-process/SKILL.md b/skills/stakeholder-decision-making-using-toc-thinking-process/SKILL.md deleted file mode 100644 index 931c2065..00000000 --- a/skills/stakeholder-decision-making-using-toc-thinking-process/SKILL.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -name: stakeholder-decision-making-using-toc-thinking-process -description: >- - Stakeholder decision-making using TOC thinking process. Use when the user needs a product - workflow for stakeholder management related to stakeholder decision-making using toc - thinking process. Trigger terms: decision-making, stakeholders, theory-of-constraints, - problem-solving, stakeholder-management. ---- - - - -# Stakeholder decision-making using TOC thinking process - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `stakeholder-decision-making-using-toc-thinking-process` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: TOC stakeholder decision analysis with conflict, assumptions, undesirable effects, root causes, recommendations, and stakeholder considerations - -Use this skill to run the Productize prompt contract for **Stakeholder decision-making using TOC thinking process**. - -## Decision-Making Boundary - -Use this skill when the stakeholder decision problem is structured as a conflict, constraint, -or cause-effect chain. It should improve stakeholder decision quality by surfacing assumptions, -undesirable effects, root causes, and stakeholder concerns. - -Do not use it for broad strategic decision bias review, group decision process design, or -role-identity mapping unless TOC conflict/root-cause logic is the requested method. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} -- {{STAKEHOLDER_INFO}} - - -GOAL -Produce a high-quality deliverable for: Stakeholder decision-making using TOC thinking process. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{PROBLEM_STATEMENT}}` and `{{STAKEHOLDER_INFO}}` to support stakeholder decision-making using TOC thinking processes. -- Identify and clearly state the core problem. -- Apply Evaporating Cloud: -- Define conflict. -- Identify requirements. -- Uncover assumptions. -- Challenge assumptions. -- Generate potential solutions. -- Apply Effect-Cause-Effect: -- Identify undesirable effects. -- Trace effects to causes. -- Identify root causes. -- Produce actionable recommendations and explicitly connect them to stakeholder concerns/interests. - -FORMAT -Return exactly this structure: - - -1. Problem Identification: - [Clearly state the core problem] - -2. Evaporating Cloud Analysis: - a. Conflict: [Describe the main conflict] - b. Requirements: [List the key requirements] - c. Assumptions: [Identify important assumptions] - d. Challenged Assumptions: [Explain how assumptions were challenged] - e. Potential Solutions: [List generated solutions] - -3. Effect-Cause-Effect Analysis: - a. Undesirable Effects: [List the main undesirable effects] - b. Causes: [Explain the causes linked to each effect] - c. Root Causes: [Identify the fundamental root causes] - -4. Recommendations: - [Provide specific, actionable recommendations based on your analysis] - -5. Stakeholder Considerations: - [Explain how your recommendations address stakeholder concerns and interests] - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Evaporating Cloud or Effect-Cause-Effect steps are missing or not logically connected. -- Recommendations are generic, non-actionable, or not tied to stakeholder considerations. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-decision-making-using-toc-thinking-process/SKILL.md.tmpl b/skills/stakeholder-decision-making-using-toc-thinking-process/SKILL.md.tmpl deleted file mode 100644 index d919a225..00000000 --- a/skills/stakeholder-decision-making-using-toc-thinking-process/SKILL.md.tmpl +++ /dev/null @@ -1,96 +0,0 @@ ---- -name: stakeholder-decision-making-using-toc-thinking-process -description: >- - Stakeholder decision-making using TOC thinking process. Use when the user needs a product - workflow for stakeholder management related to stakeholder decision-making using toc - thinking process. Trigger terms: decision-making, stakeholders, theory-of-constraints, - problem-solving, stakeholder-management. ---- -# Stakeholder decision-making using TOC thinking process - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Stakeholder decision-making using TOC thinking process**. - -## Decision-Making Boundary - -Use this skill when the stakeholder decision problem is structured as a conflict, constraint, -or cause-effect chain. It should improve stakeholder decision quality by surfacing assumptions, -undesirable effects, root causes, and stakeholder concerns. - -Do not use it for broad strategic decision bias review, group decision process design, or -role-identity mapping unless TOC conflict/root-cause logic is the requested method. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM_STATEMENT}} -- {{STAKEHOLDER_INFO}} - - -GOAL -Produce a high-quality deliverable for: Stakeholder decision-making using TOC thinking process. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{PROBLEM_STATEMENT}}` and `{{STAKEHOLDER_INFO}}` to support stakeholder decision-making using TOC thinking processes. -- Identify and clearly state the core problem. -- Apply Evaporating Cloud: -- Define conflict. -- Identify requirements. -- Uncover assumptions. -- Challenge assumptions. -- Generate potential solutions. -- Apply Effect-Cause-Effect: -- Identify undesirable effects. -- Trace effects to causes. -- Identify root causes. -- Produce actionable recommendations and explicitly connect them to stakeholder concerns/interests. - -FORMAT -Return exactly this structure: - - -1. Problem Identification: - [Clearly state the core problem] - -2. Evaporating Cloud Analysis: - a. Conflict: [Describe the main conflict] - b. Requirements: [List the key requirements] - c. Assumptions: [Identify important assumptions] - d. Challenged Assumptions: [Explain how assumptions were challenged] - e. Potential Solutions: [List generated solutions] - -3. Effect-Cause-Effect Analysis: - a. Undesirable Effects: [List the main undesirable effects] - b. Causes: [Explain the causes linked to each effect] - c. Root Causes: [Identify the fundamental root causes] - -4. Recommendations: - [Provide specific, actionable recommendations based on your analysis] - -5. Stakeholder Considerations: - [Explain how your recommendations address stakeholder concerns and interests] - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Evaporating Cloud or Effect-Cause-Effect steps are missing or not logically connected. -- Recommendations are generic, non-actionable, or not tied to stakeholder considerations. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-decision-making-using-toc-thinking-process/agents/openai.yaml b/skills/stakeholder-decision-making-using-toc-thinking-process/agents/openai.yaml deleted file mode 100644 index 71c1e4be..00000000 --- a/skills/stakeholder-decision-making-using-toc-thinking-process/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Stakeholder decision-making using TOC thinking process" - short_description: "Stakeholder decision-making using TOC thinking process. Use when the user needs a product workflow for stakeholder..." - brand_color: "#7C2D12" - default_prompt: "Use $stakeholder-decision-making-using-toc-thinking-process with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/stakeholder-decision-making-using-toc-thinking-process/productize.json b/skills/stakeholder-decision-making-using-toc-thinking-process/productize.json deleted file mode 100644 index 9e3a5190..00000000 --- a/skills/stakeholder-decision-making-using-toc-thinking-process/productize.json +++ /dev/null @@ -1,40 +0,0 @@ -{ - "title": "Stakeholder decision-making using TOC thinking process", - "category": "Decision Making", - "lifecycle": "Align", - "tags": [ - "stakeholder-decision-making-using-toc-thinking-process", - "stakeholder", - "decision", - "making", - "toc", - "thinking", - "process" - ], - "use_when": "Use when a stakeholder decision is blocked by conflict, constraints, undesirable effects, or cause-effect disagreement and the user wants Theory of Constraints thinking process logic.", - "do_not_use_when": "Do not use for general strategic decision bias review, group decision process design, visual decision review, or role identity mapping unless TOC conflict/root-cause logic is requested.", - "output_artifact": "TOC stakeholder decision analysis with conflict, assumptions, undesirable effects, root causes, recommendations, and stakeholder considerations", - "routing_signals": [ - "stakeholder-decision-making-using-toc-thinking-process", - "stakeholder", - "decision", - "making", - "toc", - "thinking", - "process", - "constraints", - "undesirable-effects" - ], - "framework_fit": "Best when the product work is explicitly about decision making and the requested method fits Stakeholder decision-making using TOC thinking process.", - "failure_modes": [ - "Produces TOC stakeholder decision analysis with conflict, assumptions, undesirable effects, root causes, recommendations, and stakeholder considerations without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Stakeholder decision-making using TOC thinking process as generic Decision Making advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Stakeholder decision-making using TOC thinking process when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $stakeholder-decision-making-using-toc-thinking-process to resolve a conflict between sales needing enterprise features and product needing onboarding improvements.", - "expected_artifact": "TOC stakeholder decision analysis with conflict, assumptions, undesirable effects, root causes, recommendations, and stakeholder considerations" - } - ] -} diff --git a/skills/stakeholder-moo-objections-and-product-derailment-risks/SKILL.md b/skills/stakeholder-moo-objections-and-product-derailment-risks/SKILL.md deleted file mode 100644 index ad963f74..00000000 --- a/skills/stakeholder-moo-objections-and-product-derailment-risks/SKILL.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -name: stakeholder-moo-objections-and-product-derailment-risks -description: >- - Stakeholder MOO objections and product derailment risks. Use when the user needs a product - workflow for stakeholder management related to stakeholder moo objections and product - derailment risks. Trigger terms: stakeholder-management, risk-management, product-strategy, - communication. ---- - - - -# Stakeholder MOO objections and product derailment risks - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `stakeholder-moo-objections-and-product-derailment-risks` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Stakeholder MOO objections and product derailment risks stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Stakeholder MOO objections and product derailment risks**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Stakeholder MOO objections and product derailment risks. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Apply MOO (Most Obvious Objection) analysis to stakeholder risk/derailment scenarios. -- First collect only essential context; ask concise follow-ups with a maximum of 5 questions total if needed. -- If sufficient context exists, produce: -- `BLUF` with top 3 stakeholder-voice MOOs, why obvious, confidence, and QBQ. -- Stakeholder objection mapping with objection type, MOO rank, QBQ, loss/gain framing, frequency x magnitude, evidence requested, counter-moves, and decision thresholds. -- Red-team drill questions, proof and pre-wire plan, executive one-slide summary, risk register, and vibe-check behaviors. -- Use plain, scannable language; label assumptions/uncertainties; prioritize obvious objections first; include numbers where possible. -- Ensure edge-case objections are covered (data quality, privacy, model eval/bias when relevant, scale/support load, contracts/channel conflict/cannibalization, change management, measurement validity). -- If context is insufficient, output only: -- A 5-question minimal follow-up. -- A clearly labeled provisional top-3 MOO guess. - -FORMAT -Return exactly this structure: - -If context is insufficient: -Minimal Follow-up (5 questions) -1. [question] -2. [question] -3. [question] -4. [question] -5. [question] -Provisional Top-3 MOO Guess (clearly labeled) -- [MOO 1] -- [MOO 2] -- [MOO 3] - -If context is sufficient: -A) BLUF - Top 3 MOOs -- [stakeholder-voice objection + why obvious + confidence + QBQ] - -B) Stakeholder Objection Map -| Stakeholder Group | Objection | Type | MOO Rank (1-5) | QBQ | Loss vs Gain | Freq x Magnitude | Evidence Asked | Counter-moves | Decision Threshold | -| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | [row] | [row] | [row] | [row] | - -C) Red-Team Drill -- [5-10 sharp questions] - -D) Proof & Pre-Wire Plan -Fast proof stack: -- [test] -Artifacts: -- [artifact] -Pre-wire scripts: -- Email/Slack template (<=120 words): [text] -- 60-sec live opener: [text] -- If-they-say-X, you-say-Y snippets (top 3): [text] - -E) Executive Slide (1 slide) -Title: [text] -- Why now: [text] -- Top MOO + QBQ: [text] -- Evidence to date: [text] -- Next proof step + decision gate: [text] -- Ask (people/time/budget) + trade-offs: [text] - -F) Risk Register -| Risk | Trigger | Early Warning Signal | Owner | Mitigation | Kill-switch | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -G) Vibe Check -Behaviors to avoid: -- [item] -Grounded behaviors to show: -- [item] - -FAILURE -- Does not follow the conditional output path (insufficient-context vs sufficient-context). -- Missing required MOO sections (`A` through `G`) when context is sufficient. -- Objection map lacks required fields (type, rank, QBQ, evidence, threshold, counter-moves). -- Red-team, proof/pre-wire, risk register, or vibe-check sections are missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-moo-objections-and-product-derailment-risks/SKILL.md.tmpl b/skills/stakeholder-moo-objections-and-product-derailment-risks/SKILL.md.tmpl deleted file mode 100644 index 0d61458e..00000000 --- a/skills/stakeholder-moo-objections-and-product-derailment-risks/SKILL.md.tmpl +++ /dev/null @@ -1,115 +0,0 @@ ---- -name: stakeholder-moo-objections-and-product-derailment-risks -description: >- - Stakeholder MOO objections and product derailment risks. Use when the user needs a product - workflow for stakeholder management related to stakeholder moo objections and product - derailment risks. Trigger terms: stakeholder-management, risk-management, product-strategy, - communication. ---- -# Stakeholder MOO objections and product derailment risks - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Stakeholder MOO objections and product derailment risks**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: Stakeholder MOO objections and product derailment risks. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Apply MOO (Most Obvious Objection) analysis to stakeholder risk/derailment scenarios. -- First collect only essential context; ask concise follow-ups with a maximum of 5 questions total if needed. -- If sufficient context exists, produce: -- `BLUF` with top 3 stakeholder-voice MOOs, why obvious, confidence, and QBQ. -- Stakeholder objection mapping with objection type, MOO rank, QBQ, loss/gain framing, frequency x magnitude, evidence requested, counter-moves, and decision thresholds. -- Red-team drill questions, proof and pre-wire plan, executive one-slide summary, risk register, and vibe-check behaviors. -- Use plain, scannable language; label assumptions/uncertainties; prioritize obvious objections first; include numbers where possible. -- Ensure edge-case objections are covered (data quality, privacy, model eval/bias when relevant, scale/support load, contracts/channel conflict/cannibalization, change management, measurement validity). -- If context is insufficient, output only: -- A 5-question minimal follow-up. -- A clearly labeled provisional top-3 MOO guess. - -FORMAT -Return exactly this structure: - -If context is insufficient: -Minimal Follow-up (5 questions) -1. [question] -2. [question] -3. [question] -4. [question] -5. [question] -Provisional Top-3 MOO Guess (clearly labeled) -- [MOO 1] -- [MOO 2] -- [MOO 3] - -If context is sufficient: -A) BLUF - Top 3 MOOs -- [stakeholder-voice objection + why obvious + confidence + QBQ] - -B) Stakeholder Objection Map -| Stakeholder Group | Objection | Type | MOO Rank (1-5) | QBQ | Loss vs Gain | Freq x Magnitude | Evidence Asked | Counter-moves | Decision Threshold | -| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | [row] | [row] | [row] | [row] | - -C) Red-Team Drill -- [5-10 sharp questions] - -D) Proof & Pre-Wire Plan -Fast proof stack: -- [test] -Artifacts: -- [artifact] -Pre-wire scripts: -- Email/Slack template (<=120 words): [text] -- 60-sec live opener: [text] -- If-they-say-X, you-say-Y snippets (top 3): [text] - -E) Executive Slide (1 slide) -Title: [text] -- Why now: [text] -- Top MOO + QBQ: [text] -- Evidence to date: [text] -- Next proof step + decision gate: [text] -- Ask (people/time/budget) + trade-offs: [text] - -F) Risk Register -| Risk | Trigger | Early Warning Signal | Owner | Mitigation | Kill-switch | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -G) Vibe Check -Behaviors to avoid: -- [item] -Grounded behaviors to show: -- [item] - -FAILURE -- Does not follow the conditional output path (insufficient-context vs sufficient-context). -- Missing required MOO sections (`A` through `G`) when context is sufficient. -- Objection map lacks required fields (type, rank, QBQ, evidence, threshold, counter-moves). -- Red-team, proof/pre-wire, risk register, or vibe-check sections are missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-moo-objections-and-product-derailment-risks/agents/openai.yaml b/skills/stakeholder-moo-objections-and-product-derailment-risks/agents/openai.yaml deleted file mode 100644 index a32052a6..00000000 --- a/skills/stakeholder-moo-objections-and-product-derailment-risks/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Stakeholder MOO objections and product derailment risks" - short_description: "Stakeholder MOO objections and product derailment risks. Use when the user needs a product workflow for stakeholder..." - brand_color: "#0891B2" - default_prompt: "Use $stakeholder-moo-objections-and-product-derailment-risks with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/stakeholder-moo-objections-and-product-derailment-risks/productize.json b/skills/stakeholder-moo-objections-and-product-derailment-risks/productize.json deleted file mode 100644 index 89088130..00000000 --- a/skills/stakeholder-moo-objections-and-product-derailment-risks/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Stakeholder MOO objections and product derailment risks", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "stakeholder-moo-objections-and-product-derailment-risks", - "stakeholder", - "moo", - "objections", - "derailment", - "risks" - ], - "use_when": "Stakeholder MOO objections and product derailment risks. Use when the user needs a product workflow for stakeholder management related to stakeholder moo objections and product derailment risks. Trigger terms: stakeholder-management, risk-management, product-strategy, communication.", - "do_not_use_when": "Do not use Stakeholder MOO objections and product derailment risks when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Stakeholder MOO objections and product derailment risks stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "stakeholder-moo-objections-and-product-derailment-risks", - "stakeholder", - "moo", - "objections", - "derailment", - "risks" - ], - "framework_fit": "Stakeholder MOO objections and product derailment risks fits Stakeholder Communication work in the Align lifecycle when the user needs Stakeholder MOO objections and product derailment risks stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Stakeholder MOO objections and product derailment risks stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Stakeholder MOO objections and product derailment risks as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Stakeholder MOO objections and product derailment risks when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $stakeholder-moo-objections-and-product-derailment-risks to turn this stakeholder context into a decision-ready Stakeholder MOO objections and product derailment risks stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Stakeholder MOO objections and product derailment risks stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/stakeholder-power-interest-and-influence-map/SKILL.md b/skills/stakeholder-power-interest-and-influence-map/SKILL.md deleted file mode 100644 index 1124f8a8..00000000 --- a/skills/stakeholder-power-interest-and-influence-map/SKILL.md +++ /dev/null @@ -1,168 +0,0 @@ ---- -name: stakeholder-power-interest-and-influence-map -description: >- - Stakeholder Powerโ€“Interest & Influence Map. Use when the user needs a product workflow for - stakeholder management related to stakeholder powerโ€“interest & influence map. Trigger terms: - stakeholder-management, influence, internal-politics, communication. ---- - - - -# Stakeholder Powerโ€“Interest & Influence Map - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `stakeholder-power-interest-and-influence-map` -- **Lifecycle**: Align -- **Category**: Decision Making -- **Primary artifact**: Stakeholder decision influence map with power-interest matrix, influence pyramid, role identity risks, engagement plan, and mitigations - -Use this skill to run the Productize prompt contract for **Stakeholder Powerโ€“Interest & Influence Map**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Stakeholder Powerโ€“Interest & Influence Map". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a stakeholder strategy output from initiative context and stakeholder details. -- If critical stakeholder context is missing, ask exactly 3 targeted questions; if still unclear, state assumptions and proceed. -- Produce: -- A Power-Interest 2x2 matrix with named stakeholders per quadrant. -- An Influence Pyramid (Top/Middle/Base) including informal power roles (gatekeepers, super-connectors, executive assistants where relevant). -- High-power stakeholder profiles covering goals/metrics, concerns/risks, preferred comms style, and political risks. -- Decision-making profile covering role identity, expected role behavior, likely information filters, in-group/out-group dynamics, and susceptibility to role pressure when relevant. -- A tailored engagement plan per high-power stakeholder (cadence/channel, format/owner, key message, quick win, fallback). -- A plan to inform/mobilize high-interest low-power stakeholders. -- Success signals/metrics and top 3 prioritized political pitfalls with mitigations. - -FORMAT -Return exactly this structure: - -Power-Interest Matrix -| Quadrant | Stakeholders | -| --- | --- | -| High Power / High Interest | [names] | -| High Power / Low Interest | [names] | -| Low Power / High Interest | [names] | -| Low Power / Low Interest | [names] | - -Influence Pyramid -- Top: [names + rationale] -- Middle: [names + rationale] -- Base: [names + rationale] - -High-Power Profiles -| Stakeholder | Goals & Success Metrics | Likely Concerns/Risks | Role Identity / Expected Behavior | Preferred Communication Style | Political Risks for Me | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -Decision-Making Influence Risks -- Role pressure: [who may decide from role expectation rather than evidence] -- In-group / out-group effects: [groups and likely interpretation gap] -- Authority or conformity risk: [risk and mitigation] -- Common-information risk: [shared info that may crowd out unique evidence] - -Engagement Plan -| Stakeholder | Cadence & Channel | Format | Owner | Key Message | Quick Win | Fallback | -| --- | --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | [row] | - -Advocacy Plan (High-Interest / Low-Power) -- [how to inform] -- [how to mobilize advocacy] - -Success Signals & Metrics -- [signal/metric] - -Risks & Mitigations -1. [pitfall + mitigation] -2. [pitfall + mitigation] -3. [pitfall + mitigation] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section/table is missing or materially incomplete. -- High-power stakeholders are not profiled and mapped to tailored engagement actions. -- Informal influence is ignored or unsupported. -- Role identity, in-group/out-group effects, or group decision influence risks are ignored when relevant. -- Top 3 political pitfalls and mitigations are missing, unprioritized, or generic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `power interest grid`, `stakeholder communication plan`, `raci`, `escalation path`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/stakeholder-power-interest-and-influence-map/SKILL.md.tmpl b/skills/stakeholder-power-interest-and-influence-map/SKILL.md.tmpl deleted file mode 100644 index 7363f1cd..00000000 --- a/skills/stakeholder-power-interest-and-influence-map/SKILL.md.tmpl +++ /dev/null @@ -1,109 +0,0 @@ ---- -name: stakeholder-power-interest-and-influence-map -description: >- - Stakeholder Powerโ€“Interest & Influence Map. Use when the user needs a product workflow for - stakeholder management related to stakeholder powerโ€“interest & influence map. Trigger terms: - stakeholder-management, influence, internal-politics, communication. ---- -# Stakeholder Powerโ€“Interest & Influence Map - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Stakeholder Powerโ€“Interest & Influence Map**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Stakeholder Powerโ€“Interest & Influence Map". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Build a stakeholder strategy output from initiative context and stakeholder details. -- If critical stakeholder context is missing, ask exactly 3 targeted questions; if still unclear, state assumptions and proceed. -- Produce: -- A Power-Interest 2x2 matrix with named stakeholders per quadrant. -- An Influence Pyramid (Top/Middle/Base) including informal power roles (gatekeepers, super-connectors, executive assistants where relevant). -- High-power stakeholder profiles covering goals/metrics, concerns/risks, preferred comms style, and political risks. -- Decision-making profile covering role identity, expected role behavior, likely information filters, in-group/out-group dynamics, and susceptibility to role pressure when relevant. -- A tailored engagement plan per high-power stakeholder (cadence/channel, format/owner, key message, quick win, fallback). -- A plan to inform/mobilize high-interest low-power stakeholders. -- Success signals/metrics and top 3 prioritized political pitfalls with mitigations. - -FORMAT -Return exactly this structure: - -Power-Interest Matrix -| Quadrant | Stakeholders | -| --- | --- | -| High Power / High Interest | [names] | -| High Power / Low Interest | [names] | -| Low Power / High Interest | [names] | -| Low Power / Low Interest | [names] | - -Influence Pyramid -- Top: [names + rationale] -- Middle: [names + rationale] -- Base: [names + rationale] - -High-Power Profiles -| Stakeholder | Goals & Success Metrics | Likely Concerns/Risks | Role Identity / Expected Behavior | Preferred Communication Style | Political Risks for Me | -| --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | - -Decision-Making Influence Risks -- Role pressure: [who may decide from role expectation rather than evidence] -- In-group / out-group effects: [groups and likely interpretation gap] -- Authority or conformity risk: [risk and mitigation] -- Common-information risk: [shared info that may crowd out unique evidence] - -Engagement Plan -| Stakeholder | Cadence & Channel | Format | Owner | Key Message | Quick Win | Fallback | -| --- | --- | --- | --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | [row] | [row] | [row] | - -Advocacy Plan (High-Interest / Low-Power) -- [how to inform] -- [how to mobilize advocacy] - -Success Signals & Metrics -- [signal/metric] - -Risks & Mitigations -1. [pitfall + mitigation] -2. [pitfall + mitigation] -3. [pitfall + mitigation] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section/table is missing or materially incomplete. -- High-power stakeholders are not profiled and mapped to tailored engagement actions. -- Informal influence is ignored or unsupported. -- Role identity, in-group/out-group effects, or group decision influence risks are ignored when relevant. -- Top 3 political pitfalls and mitigations are missing, unprioritized, or generic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `power interest grid`, `stakeholder communication plan`, `raci`, `escalation path`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/stakeholder-power-interest-and-influence-map/agents/openai.yaml b/skills/stakeholder-power-interest-and-influence-map/agents/openai.yaml deleted file mode 100644 index 624d4847..00000000 --- a/skills/stakeholder-power-interest-and-influence-map/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Stakeholder Powerโ€“Interest & Influence Map" - short_description: "Stakeholder Powerโ€“Interest & Influence Map. Use when the user needs a product workflow for stakeholder management..." - brand_color: "#7C2D12" - default_prompt: "Use $stakeholder-power-interest-and-influence-map with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/stakeholder-power-interest-and-influence-map/productize.json b/skills/stakeholder-power-interest-and-influence-map/productize.json deleted file mode 100644 index 981128d6..00000000 --- a/skills/stakeholder-power-interest-and-influence-map/productize.json +++ /dev/null @@ -1,51 +0,0 @@ -{ - "title": "Stakeholder Powerโ€“Interest & Influence Map", - "category": "Decision Making", - "lifecycle": "Align", - "tags": [ - "stakeholder-power-interest-and-influence-map", - "stakeholder", - "power", - "interest", - "influence", - "map", - "power-interest-grid", - "stakeholder-communication-plan", - "raci", - "escalation-path" - ], - "use_when": "Use when a decision depends on stakeholder power, influence, role expectations, informal authority, political risks, or decision support across stakeholders.", - "do_not_use_when": "Do not use when role identity, organizational identity, or in-group/out-group dynamics are the central issue; use role-identity-decision-making-map.", - "output_artifact": "Stakeholder decision influence map with power-interest matrix, influence pyramid, role identity risks, engagement plan, and mitigations", - "routing_signals": [ - "stakeholder-power-interest-and-influence-map", - "stakeholder", - "power", - "interest", - "influence", - "map", - "power-interest-grid", - "stakeholder-communication-plan", - "raci", - "escalation-path", - "role-expectations", - "informal-authority", - "political-risks", - "or-decision-support-across-stakeholders" - ], - "framework_fit": "Best when the product work is explicitly about decision making and the requested method fits Stakeholder Powerโ€“Interest & Influence Map.", - "failure_modes": [ - "Produces Stakeholder decision influence map with power-interest matrix, influence pyramid, role identity risks, engagement plan, and mitigations without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Stakeholder Powerโ€“Interest & Influence Map as generic Decision Making advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Stakeholder Powerโ€“Interest & Influence Map when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $stakeholder-power-interest-and-influence-map to map who can influence the pricing-change decision, their power, role expectations, political risks, and engagement plan.", - "expected_artifact": "Stakeholder decision influence map with power-interest matrix, influence pyramid, role identity risks, engagement plan, and mitigations" - } - ], - "references": [ - "references/pm-skills-main-merge.md" - ] -} diff --git a/skills/stakeholder-power-interest-and-influence-map/references/pm-skills-main-merge.md b/skills/stakeholder-power-interest-and-influence-map/references/pm-skills-main-merge.md deleted file mode 100644 index 40ac801c..00000000 --- a/skills/stakeholder-power-interest-and-influence-map/references/pm-skills-main-merge.md +++ /dev/null @@ -1,59 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to add a power-interest grid, quadrant-specific communication plan, escalation path, and optional RACI matrix. - -## Routing Signals - -- power interest grid -- stakeholder communication plan -- raci -- escalation path - -## pm-execution/skills/stakeholder-map/SKILL.md - -## Stakeholder Mapping & Communication Plan - -Map stakeholders on a Power x Interest grid and create a tailored communication plan for each group. - -### Context - -You are helping build a stakeholder map for **$ARGUMENTS**. - -If the user provides files (org charts, project briefs, team rosters), read them first. If they describe the product or initiative, use that context to infer likely stakeholders. - -### Instructions - -1. **Identify stakeholders**: List all relevant individuals and groups -- executives, engineering leads, designers, marketing, sales, support, legal, finance, external partners, and end users. - -2. **Classify each stakeholder** on two dimensions: - - **Power** (High/Low): Their ability to influence decisions, resources, or outcomes - - **Interest** (High/Low): How much the project directly affects them or how engaged they are - -3. **Place stakeholders in the Power x Interest grid**: - - | | High Interest | Low Interest | - |---|---|---| - | **High Power** | **Manage Closely** -- Regular 1:1s, involve in decisions, seek their input early | **Keep Satisfied** -- Periodic updates, escalate only critical issues | - | **Low Power** | **Keep Informed** -- Regular status updates, invite to demos, gather feedback | **Monitor** -- Light-touch updates, available on request | - -4. **For each quadrant**, recommend: - - Communication frequency (daily, weekly, bi-weekly, monthly) - - Communication format (1:1, email, Slack, meeting, dashboard) - - Key messages and framing - - Potential risks if this stakeholder is neglected - -5. **Create a communication plan table**: - - | Stakeholder | Role | Power | Interest | Strategy | Frequency | Channel | Key Message | - |---|---|---|---|---|---|---|---| - -6. **Flag potential conflicts**: Identify stakeholders with competing interests and suggest alignment strategies. - -Think step by step. Save the stakeholder map as a markdown document. - ---- - -### Further Reading - -- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium) -- [Team Topologies: A Handbook to Set and Scale Product Teams](https://www.productcompass.pm/p/team-topologies-a-handbook-to-set) diff --git a/skills/stakeholder-risk-review-for-a-feature-or-prd/SKILL.md b/skills/stakeholder-risk-review-for-a-feature-or-prd/SKILL.md deleted file mode 100644 index 659d6af5..00000000 --- a/skills/stakeholder-risk-review-for-a-feature-or-prd/SKILL.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -name: stakeholder-risk-review-for-a-feature-or-prd -description: >- - Stakeholder Risk Review for a Feature or PRD. Use when the user needs a product workflow for - stakeholder management related to stakeholder risk review for a feature or prd. Trigger - terms: stakeholder-management, risk-management, product-management, communication, - internal-politics. ---- - - - -# Stakeholder Risk Review for a Feature or PRD - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `stakeholder-risk-review-for-a-feature-or-prd` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Stakeholder Risk Review for a Feature or PRD delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Stakeholder Risk Review for a Feature or PRD**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Stakeholder Risk Review for a Feature or PRD". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Review a feature/PRD for stakeholder and political risk before broad circulation. -- Build a Power-Interest snapshot (with named stakeholders) and include informal influencers. -- Identify stakeholders likely to feel threatened/excluded/overruled and articulate concrete objections. -- Provide mitigation guidance in two tracks: -- Document improvements (evidence, ownership, metrics, clarifications). -- 1:1 stakeholder messaging (focus, proof points, artifacts). -- Recommend exactly 3 pre-work actions before broad sharing. -- Provide framing variations for execs vs ICs and a minimal comms sequence. -- List top decision/optics risks with mitigations (pilot scope, phased rollout, sunset criteria, contingencies). -- Provide a practical readiness checklist (data, owners, dependencies, support, legal/privacy where relevant). - -FORMAT -Return exactly this structure: - -Power-Interest Snapshot -| Quadrant | Stakeholders | -| --- | --- | -| High Power / High Interest | [names] | -| High Power / Low Interest | [names] | -| Low Power / High Interest | [names] | -| Low Power / Low Interest | [names] | -Informal influencers: [names and why] - -Stakeholder Concerns -| Stakeholder | Concern | Evidence Needed | Suggested Response | -| --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | - -Doc Changes -- [specific PRD/doc edit] - -1:1 Messages -- [Stakeholder]: [message focus, proof points, artifacts] - -Pre-Work: Top 3 Actions -1. [action] -2. [action] -3. [action] - -Framing & Comms Sequence -Exec framing: [benefits, risks, ask] -IC framing: [benefits, risks, ask] -Comms sequence: -1. [step] -2. [step] -3. [step] - -Risks & Mitigations -| Risk | Why it matters | Mitigation | Owner | -| --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | - -Readiness Checklist -- [ ] Data readiness confirmed -- [ ] Owners assigned -- [ ] Dependencies mapped -- [ ] Support plan defined -- [ ] Legal/privacy review completed (if applicable) -- [ ] [additional item] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Fewer or more than 3 items in `Pre-Work: Top 3 Actions`. -- Stakeholder concerns are generic or lack evidence/response mapping. -- Power-Interest snapshot omits names or ignores informal influencers. -- Risks/mitigations are not actionable or lack ownership. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-risk-review-for-a-feature-or-prd/SKILL.md.tmpl b/skills/stakeholder-risk-review-for-a-feature-or-prd/SKILL.md.tmpl deleted file mode 100644 index 3eb6c5cf..00000000 --- a/skills/stakeholder-risk-review-for-a-feature-or-prd/SKILL.md.tmpl +++ /dev/null @@ -1,111 +0,0 @@ ---- -name: stakeholder-risk-review-for-a-feature-or-prd -description: >- - Stakeholder Risk Review for a Feature or PRD. Use when the user needs a product workflow for - stakeholder management related to stakeholder risk review for a feature or prd. Trigger - terms: stakeholder-management, risk-management, product-management, communication, - internal-politics. ---- -# Stakeholder Risk Review for a Feature or PRD - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Stakeholder Risk Review for a Feature or PRD**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Produce a high-quality deliverable for: "Stakeholder Risk Review for a Feature or PRD". -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Review a feature/PRD for stakeholder and political risk before broad circulation. -- Build a Power-Interest snapshot (with named stakeholders) and include informal influencers. -- Identify stakeholders likely to feel threatened/excluded/overruled and articulate concrete objections. -- Provide mitigation guidance in two tracks: -- Document improvements (evidence, ownership, metrics, clarifications). -- 1:1 stakeholder messaging (focus, proof points, artifacts). -- Recommend exactly 3 pre-work actions before broad sharing. -- Provide framing variations for execs vs ICs and a minimal comms sequence. -- List top decision/optics risks with mitigations (pilot scope, phased rollout, sunset criteria, contingencies). -- Provide a practical readiness checklist (data, owners, dependencies, support, legal/privacy where relevant). - -FORMAT -Return exactly this structure: - -Power-Interest Snapshot -| Quadrant | Stakeholders | -| --- | --- | -| High Power / High Interest | [names] | -| High Power / Low Interest | [names] | -| Low Power / High Interest | [names] | -| Low Power / Low Interest | [names] | -Informal influencers: [names and why] - -Stakeholder Concerns -| Stakeholder | Concern | Evidence Needed | Suggested Response | -| --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | - -Doc Changes -- [specific PRD/doc edit] - -1:1 Messages -- [Stakeholder]: [message focus, proof points, artifacts] - -Pre-Work: Top 3 Actions -1. [action] -2. [action] -3. [action] - -Framing & Comms Sequence -Exec framing: [benefits, risks, ask] -IC framing: [benefits, risks, ask] -Comms sequence: -1. [step] -2. [step] -3. [step] - -Risks & Mitigations -| Risk | Why it matters | Mitigation | Owner | -| --- | --- | --- | --- | -| [row] | [row] | [row] | [row] | - -Readiness Checklist -- [ ] Data readiness confirmed -- [ ] Owners assigned -- [ ] Dependencies mapped -- [ ] Support plan defined -- [ ] Legal/privacy review completed (if applicable) -- [ ] [additional item] - -Assumptions -- [assumption or "None"] - -FAILURE -- Any required section is missing or materially incomplete. -- Fewer or more than 3 items in `Pre-Work: Top 3 Actions`. -- Stakeholder concerns are generic or lack evidence/response mapping. -- Power-Interest snapshot omits names or ignores informal influencers. -- Risks/mitigations are not actionable or lack ownership. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/stakeholder-risk-review-for-a-feature-or-prd/agents/openai.yaml b/skills/stakeholder-risk-review-for-a-feature-or-prd/agents/openai.yaml deleted file mode 100644 index f70e252a..00000000 --- a/skills/stakeholder-risk-review-for-a-feature-or-prd/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Stakeholder Risk Review for a Feature or PRD" - short_description: "Stakeholder Risk Review for a Feature or PRD. Use when the user needs a product workflow for stakeholder management..." - brand_color: "#4F46E5" - default_prompt: "Use $stakeholder-risk-review-for-a-feature-or-prd with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/stakeholder-risk-review-for-a-feature-or-prd/productize.json b/skills/stakeholder-risk-review-for-a-feature-or-prd/productize.json deleted file mode 100644 index ad4af0b5..00000000 --- a/skills/stakeholder-risk-review-for-a-feature-or-prd/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Stakeholder Risk Review for a Feature or PRD", - "category": "Delivery", - "lifecycle": "Plan", - "tags": [ - "stakeholder-risk-review-for-a-feature-or-prd", - "stakeholder", - "risk", - "review", - "feature", - "prd" - ], - "use_when": "Stakeholder Risk Review for a Feature or PRD. Use when the user needs a product workflow for stakeholder management related to stakeholder risk review for a feature or prd. Trigger terms: stakeholder-management, risk-management, product-management, communication, internal-politics.", - "do_not_use_when": "Do not use Stakeholder Risk Review for a Feature or PRD when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Stakeholder Risk Review for a Feature or PRD delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "stakeholder-risk-review-for-a-feature-or-prd", - "stakeholder", - "risk", - "review", - "feature", - "prd" - ], - "framework_fit": "Stakeholder Risk Review for a Feature or PRD fits Delivery work in the Plan lifecycle when the user needs Stakeholder Risk Review for a Feature or PRD delivery brief with scope, requirements, priorities, risks, and acceptance criteria and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Stakeholder Risk Review for a Feature or PRD delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Stakeholder Risk Review for a Feature or PRD as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Stakeholder Risk Review for a Feature or PRD when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $stakeholder-risk-review-for-a-feature-or-prd to turn this stakeholder context into a decision-ready Stakeholder Risk Review for a Feature or PRD delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Stakeholder Risk Review for a Feature or PRD delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/stakeholder-update/SKILL.md b/skills/stakeholder-update/SKILL.md deleted file mode 100644 index 683237e2..00000000 --- a/skills/stakeholder-update/SKILL.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -name: stakeholder-update -description: >- - Generate a stakeholder update tailored to audience and cadence. Use when writing weekly or - monthly status, announcing a launch, escalating a risk or blocker, or translating progress into - executive, engineering, partner, or customer-facing versions. ---- - - - -# Stakeholder Update - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `stakeholder-update` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Stakeholder Update stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Generate a stakeholder update tailored to audience, cadence, and channel. - -## Argument Hint - -`` - -## Usage - -```text -/stakeholder-update $ARGUMENTS -``` - -## Workflow - -### 1. Determine Type - -Identify whether this is: -- Weekly status. -- Monthly summary. -- Launch announcement. -- Ad-hoc escalation, pivot, or decision update. - -### 2. Determine Audience - -Adapt content to the audience: -- Executives: brief, outcome-focused, strategic, risk-aware. -- Engineering: technical context, owners, blockers, decisions. -- Cross-functional partners: changes that affect them, asks, dependencies. -- Customers: benefits, availability, timelines, no internal jargon. -- Board: metrics, strategy, risks, concise. - -### 3. Pull Context - -If connected, use project tracker, chat, meeting notes, docs, and knowledge base to find: -- Progress since last update. -- Completed milestones. -- At-risk or blocked items. -- Decisions made or needed. -- Upcoming milestones. - -If no tools are connected, ask for accomplishments, blockers, decisions, next steps, and asks. - -### 4. Draft the Update - -Use the right template: - -**Executives** -- Status: Green, Yellow, or Red. -- TL;DR. -- Progress tied to goals. -- Risks with mitigation. -- Decisions needed and deadline. -- Next milestones. - -**Engineering** -- Shipped items with links if available. -- In-progress items with owners. -- Blockers. -- Decisions made or needed. -- Priority changes and rationale. - -**Cross-functional** -- What is coming. -- What is needed from them and by when. -- Decisions that affect their team. -- Where input is wanted. - -**Customers** -- What is new and why it matters. -- Coming soon. -- Known issues and workarounds if customer-impacting. -- Feedback channel. - -### 5. Risk and Decision Rules - -- Use Green only when genuinely on track. -- Use Yellow at first meaningful risk. -- Use Red when intervention is needed. -- Every risk should include impact, likelihood, mitigation, owner, and ask. -- Document important decisions with context, decision, consequences, and alternatives considered. - -## Output Rules - -- Lead with the conclusion. -- Match length to audience attention. -- Make asks specific. -- If there is bad news, lead with it. -- Avoid activity reporting when outcome reporting is possible. diff --git a/skills/stakeholder-update/SKILL.md.tmpl b/skills/stakeholder-update/SKILL.md.tmpl deleted file mode 100644 index da6700a4..00000000 --- a/skills/stakeholder-update/SKILL.md.tmpl +++ /dev/null @@ -1,99 +0,0 @@ ---- -name: stakeholder-update -description: >- - Generate a stakeholder update tailored to audience and cadence. Use when writing weekly or - monthly status, announcing a launch, escalating a risk or blocker, or translating progress into - executive, engineering, partner, or customer-facing versions. ---- -# Stakeholder Update - -{{PRODUCTIZE_PREAMBLE}} - -Generate a stakeholder update tailored to audience, cadence, and channel. - -## Argument Hint - -`` - -## Usage - -```text -/stakeholder-update $ARGUMENTS -``` - -## Workflow - -### 1. Determine Type - -Identify whether this is: -- Weekly status. -- Monthly summary. -- Launch announcement. -- Ad-hoc escalation, pivot, or decision update. - -### 2. Determine Audience - -Adapt content to the audience: -- Executives: brief, outcome-focused, strategic, risk-aware. -- Engineering: technical context, owners, blockers, decisions. -- Cross-functional partners: changes that affect them, asks, dependencies. -- Customers: benefits, availability, timelines, no internal jargon. -- Board: metrics, strategy, risks, concise. - -### 3. Pull Context - -If connected, use project tracker, chat, meeting notes, docs, and knowledge base to find: -- Progress since last update. -- Completed milestones. -- At-risk or blocked items. -- Decisions made or needed. -- Upcoming milestones. - -If no tools are connected, ask for accomplishments, blockers, decisions, next steps, and asks. - -### 4. Draft the Update - -Use the right template: - -**Executives** -- Status: Green, Yellow, or Red. -- TL;DR. -- Progress tied to goals. -- Risks with mitigation. -- Decisions needed and deadline. -- Next milestones. - -**Engineering** -- Shipped items with links if available. -- In-progress items with owners. -- Blockers. -- Decisions made or needed. -- Priority changes and rationale. - -**Cross-functional** -- What is coming. -- What is needed from them and by when. -- Decisions that affect their team. -- Where input is wanted. - -**Customers** -- What is new and why it matters. -- Coming soon. -- Known issues and workarounds if customer-impacting. -- Feedback channel. - -### 5. Risk and Decision Rules - -- Use Green only when genuinely on track. -- Use Yellow at first meaningful risk. -- Use Red when intervention is needed. -- Every risk should include impact, likelihood, mitigation, owner, and ask. -- Document important decisions with context, decision, consequences, and alternatives considered. - -## Output Rules - -- Lead with the conclusion. -- Match length to audience attention. -- Make asks specific. -- If there is bad news, lead with it. -- Avoid activity reporting when outcome reporting is possible. diff --git a/skills/stakeholder-update/agents/openai.yaml b/skills/stakeholder-update/agents/openai.yaml deleted file mode 100644 index 86410835..00000000 --- a/skills/stakeholder-update/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Stakeholder Update" - short_description: "Generate a stakeholder update tailored to audience and cadence. Use when writing weekly or monthly status,..." - brand_color: "#0891B2" - default_prompt: "Use $stakeholder-update with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/stakeholder-update/productize.json b/skills/stakeholder-update/productize.json deleted file mode 100644 index 3c5c686d..00000000 --- a/skills/stakeholder-update/productize.json +++ /dev/null @@ -1,44 +0,0 @@ -{ - "title": "Stakeholder Update", - "category": "Stakeholder Communication", - "tags": [ - "status-update", - "executive-communication", - "risk", - "launch", - "stakeholders", - "decision", - "stakeholder-update", - "stakeholder", - "update", - "management", - "generate", - "tailored", - "communication" - ], - "lifecycle": "Align", - "use_when": "Generate a stakeholder update tailored to audience and cadence. Use when writing weekly or monthly status, announcing a launch, escalating a risk or blocker, or translating progress into executive, engineering, partner, or customer-facing versions.", - "do_not_use_when": "Do not use Stakeholder Update when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Stakeholder Update stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "stakeholder-update", - "stakeholder", - "update", - "management", - "generate", - "tailored", - "communication" - ], - "framework_fit": "Stakeholder Update fits Stakeholder Communication work in the Align lifecycle when the user needs Stakeholder Update stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Stakeholder Update stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Stakeholder Update as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Stakeholder Update when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $stakeholder-update to turn this stakeholder context into a decision-ready Stakeholder Update stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Stakeholder Update stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/startup-canvas/SKILL.md b/skills/startup-canvas/SKILL.md deleted file mode 100644 index 00808976..00000000 --- a/skills/startup-canvas/SKILL.md +++ /dev/null @@ -1,219 +0,0 @@ ---- -name: startup-canvas -description: >- - Startup Canvas. Use when evaluating a startup concept or new product that needs product - strategy and business model logic in one founder-ready artifact. ---- - - - -# Startup Canvas - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `startup-canvas` -- **Lifecycle**: Think -- **Category**: Venture / 0-1 -- **Primary artifact**: Startup Canvas combining product strategy, business model, risks, and next validation steps - -Use when evaluating a startup concept or new product that needs product strategy and business model logic in one founder-ready artifact. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Startup Canvas combining product strategy, business model, risks, and next validation steps -- **Source method**: pm-skills-main/pm-product-strategy/skills/startup-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: startup-canvas -- **Description**: Generate a Startup Canvas for a new product. Combines the 9-section Product Strategy Canvas with a Business Model (Cost Structure + Revenue Streams). Designed specifically for startups and new products. -- **Triggers**: startup canvas, new product canvas, startup strategy, startup business model - -## Domain Context - -### Startup Canvas vs Business Model Canvas vs Lean Canvas - -Popular approaches like Business Model Canvas (Strategyzer) and Lean Canvas (Ash Maurya) mix strategy and business model into one artifact. The **Startup Canvas** (Pawe Huryn) separates them: 9 strategy sections from the Product Strategy Canvas + Cost Structure & Revenue Streams. - -**Why not Business Model Canvas?** -- No vision -- why should your team wake up every day? -- No Can't/Won't test -- what stops competitors from copying you? -- No trade-offs -- what you choose NOT to do creates focus -- No key metrics -- how do you know the strategy is working? -- Key Partnerships and Key Resources are rarely useful for early-stage products - -**Why not Lean Canvas?** -- Introduces redundancy: "Problem" overlaps with Market Segments (markets are defined by problems), "Solution" overlaps with Value Proposition (which by definition includes features) -- No vision, no trade-offs, no relative costs -- "Unfair Advantage" is too narrow -- the entire strategy should be hard to copy, not just one element -- Doesn't address the holistic fit of strategic choices reinforcing each other - -**When to use which:** -- **Business Model Canvas**: Established businesses, corporate strategy, investor materials -- **Lean Canvas**: Quick hypothesis testing when you just need speed -- **Startup Canvas**: New products where you need both strategic clarity AND a business model -- the recommended approach - -## Instructions - -You are a product strategist and startup advisor designing a Startup Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Startup Canvas that covers both the strategic choices and the business model for a new product. - -## Input Requirements -- Product or startup idea -- Target market and customer insights -- Competitive landscape -- Founder/team constraints and resources - -## Startup Canvas Template - -### Part 1: Product Strategy (9 Sections) - -**1. Vision** -- How can we inspire people? What are we aspiring to achieve? What values do we uphold? -- Start simple. Your vision will evolve alongside the strategy. - -**2. Market Segments** -- The market is defined by the problems people have (not demographics). -- Jobs to Be Done (JTBD), desired outcomes, constraints. -- What will be your first customer segment? Why this one first? - -**3. Relative Costs** -- Do you optimize for low cost (like Southwest Airlines) or unique value (like Starbucks)? -- Low costs don't necessarily mean low prices. - -**4. Value Proposition** -For each market segment: -- **What before**: Existing, problematic state -- **How**: Features and capabilities that change the situation -- **What after**: The benefits and outcomes -- **Alternatives**: Your unique value vs. competitors and substitutes (consider a Value Curve) - -**5. Trade-offs** -- What will you NOT do? Trade-offs create focus and amplify value. -- Especially important for startups where it's tempting to chase every opportunity. - -**6. Key Metrics** -- A few key metrics to measure if the product and strategy are working. -- North Star Metric and One Metric That Matters (OMTM) for this quarter. - -**7. Growth** -- Product-Led Growth or Sales-Led Growth? -- Preferred channels: Social Media, SEO, Influencers, Resellers? - -**8. Capabilities** -- What competencies and resources do you need to acquire? -- What do you build vs. partner for? - -**9. Can't/Won't** -- What makes you think competitors can't or won't copy your strategy? -- The entire strategy should be difficult to copy -- not just one element. -- Do all elements fit together and reinforce each other? - -### Part 2: Business Model - -**10. Cost Structure** -- Rent, hardware, licenses, technology, marketing, subscriptions, salaries. -- Which are recurring? How will they scale? - -**11. Revenue Streams** -- How much money from each channel? -- Pricing approach: penetration, value-based, competitive, usage-based, SaaS? -- Is the revenue model scalable? What are the biggest uncertainties? - -## Output Process -1. Define the vision and aspirational impact -2. Identify 2-3 target market segments with JTBD -3. Establish cost positioning (low cost vs premium) -4. Develop value propositions for each segment -5. List explicit trade-offs -6. Set North Star and quarterly OMTM -7. Outline growth strategy and channels -8. Document required capabilities -9. Explain defensibility (Can't/Won't test) -10. Estimate cost structure and revenue streams -11. Validate strategy coherence: do all elements reinforce each other? -12. Surface hypotheses that must be true for success -13. Suggest low-effort experiments to test key assumptions - -## Notes -- The Startup Canvas separates strategy from business model -- keep them distinct but connected -- Strategy should pass the Can't/Won't test: your competitors can't or won't copy the integrated set of choices -- After drafting the first version, identify and start testing hypotheses -- Mix and adapt approaches to suit your specific needs rather than following any canvas rigidly - ---- - -### Templates - -- [Startup Canvas (PPTX)](https://docs.google.com/presentation/d/1lA0SPflj5JT6jFV_jIDsqZJAYYperTFx/edit?usp=sharing&ouid=111307342557889008106&rtpof=true&sd=true) - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) -- [Product Strategy Canvas](https://www.productcompass.pm/p/product-strategy-canvas) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [Business Model Canvas Examples: Google Maps, Airbnb, Uber](https://www.productcompass.pm/p/business-model-canvas-examples) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/startup-canvas/SKILL.md.tmpl b/skills/startup-canvas/SKILL.md.tmpl deleted file mode 100644 index beee19b5..00000000 --- a/skills/startup-canvas/SKILL.md.tmpl +++ /dev/null @@ -1,160 +0,0 @@ ---- -name: startup-canvas -description: >- - Startup Canvas. Use when evaluating a startup concept or new product that needs product - strategy and business model logic in one founder-ready artifact. ---- -# Startup Canvas - -{{PRODUCTIZE_PREAMBLE}} - -Use when evaluating a startup concept or new product that needs product strategy and business model logic in one founder-ready artifact. - -## Productize Contract - -- **Primary lifecycle**: Think -- **Supporting lifecycle**: Strategize -- **Primary artifact**: Startup Canvas combining product strategy, business model, risks, and next validation steps -- **Source method**: pm-skills-main/pm-product-strategy/skills/startup-canvas/SKILL.md - -## Method - -## Metadata -- **Name**: startup-canvas -- **Description**: Generate a Startup Canvas for a new product. Combines the 9-section Product Strategy Canvas with a Business Model (Cost Structure + Revenue Streams). Designed specifically for startups and new products. -- **Triggers**: startup canvas, new product canvas, startup strategy, startup business model - -## Domain Context - -### Startup Canvas vs Business Model Canvas vs Lean Canvas - -Popular approaches like Business Model Canvas (Strategyzer) and Lean Canvas (Ash Maurya) mix strategy and business model into one artifact. The **Startup Canvas** (Pawe Huryn) separates them: 9 strategy sections from the Product Strategy Canvas + Cost Structure & Revenue Streams. - -**Why not Business Model Canvas?** -- No vision -- why should your team wake up every day? -- No Can't/Won't test -- what stops competitors from copying you? -- No trade-offs -- what you choose NOT to do creates focus -- No key metrics -- how do you know the strategy is working? -- Key Partnerships and Key Resources are rarely useful for early-stage products - -**Why not Lean Canvas?** -- Introduces redundancy: "Problem" overlaps with Market Segments (markets are defined by problems), "Solution" overlaps with Value Proposition (which by definition includes features) -- No vision, no trade-offs, no relative costs -- "Unfair Advantage" is too narrow -- the entire strategy should be hard to copy, not just one element -- Doesn't address the holistic fit of strategic choices reinforcing each other - -**When to use which:** -- **Business Model Canvas**: Established businesses, corporate strategy, investor materials -- **Lean Canvas**: Quick hypothesis testing when you just need speed -- **Startup Canvas**: New products where you need both strategic clarity AND a business model -- the recommended approach - -## Instructions - -You are a product strategist and startup advisor designing a Startup Canvas for $ARGUMENTS. - -Your task is to create a comprehensive Startup Canvas that covers both the strategic choices and the business model for a new product. - -## Input Requirements -- Product or startup idea -- Target market and customer insights -- Competitive landscape -- Founder/team constraints and resources - -## Startup Canvas Template - -### Part 1: Product Strategy (9 Sections) - -**1. Vision** -- How can we inspire people? What are we aspiring to achieve? What values do we uphold? -- Start simple. Your vision will evolve alongside the strategy. - -**2. Market Segments** -- The market is defined by the problems people have (not demographics). -- Jobs to Be Done (JTBD), desired outcomes, constraints. -- What will be your first customer segment? Why this one first? - -**3. Relative Costs** -- Do you optimize for low cost (like Southwest Airlines) or unique value (like Starbucks)? -- Low costs don't necessarily mean low prices. - -**4. Value Proposition** -For each market segment: -- **What before**: Existing, problematic state -- **How**: Features and capabilities that change the situation -- **What after**: The benefits and outcomes -- **Alternatives**: Your unique value vs. competitors and substitutes (consider a Value Curve) - -**5. Trade-offs** -- What will you NOT do? Trade-offs create focus and amplify value. -- Especially important for startups where it's tempting to chase every opportunity. - -**6. Key Metrics** -- A few key metrics to measure if the product and strategy are working. -- North Star Metric and One Metric That Matters (OMTM) for this quarter. - -**7. Growth** -- Product-Led Growth or Sales-Led Growth? -- Preferred channels: Social Media, SEO, Influencers, Resellers? - -**8. Capabilities** -- What competencies and resources do you need to acquire? -- What do you build vs. partner for? - -**9. Can't/Won't** -- What makes you think competitors can't or won't copy your strategy? -- The entire strategy should be difficult to copy -- not just one element. -- Do all elements fit together and reinforce each other? - -### Part 2: Business Model - -**10. Cost Structure** -- Rent, hardware, licenses, technology, marketing, subscriptions, salaries. -- Which are recurring? How will they scale? - -**11. Revenue Streams** -- How much money from each channel? -- Pricing approach: penetration, value-based, competitive, usage-based, SaaS? -- Is the revenue model scalable? What are the biggest uncertainties? - -## Output Process -1. Define the vision and aspirational impact -2. Identify 2-3 target market segments with JTBD -3. Establish cost positioning (low cost vs premium) -4. Develop value propositions for each segment -5. List explicit trade-offs -6. Set North Star and quarterly OMTM -7. Outline growth strategy and channels -8. Document required capabilities -9. Explain defensibility (Can't/Won't test) -10. Estimate cost structure and revenue streams -11. Validate strategy coherence: do all elements reinforce each other? -12. Surface hypotheses that must be true for success -13. Suggest low-effort experiments to test key assumptions - -## Notes -- The Startup Canvas separates strategy from business model -- keep them distinct but connected -- Strategy should pass the Can't/Won't test: your competitors can't or won't copy the integrated set of choices -- After drafting the first version, identify and start testing hypotheses -- Mix and adapt approaches to suit your specific needs rather than following any canvas rigidly - ---- - -### Templates - -- [Startup Canvas (PPTX)](https://docs.google.com/presentation/d/1lA0SPflj5JT6jFV_jIDsqZJAYYperTFx/edit?usp=sharing&ouid=111307342557889008106&rtpof=true&sd=true) - ---- - -### Further Reading - -- [Startup Canvas: Product Strategy and a Business Model for a New Product](https://www.productcompass.pm/p/startup-canvas) -- [Product Strategy Canvas](https://www.productcompass.pm/p/product-strategy-canvas) -- [How to Design a Value Proposition Customers Can't Resist?](https://www.productcompass.pm/p/how-to-design-value-proposition-template) -- [Business Model Canvas Examples: Google Maps, Airbnb, Uber](https://www.productcompass.pm/p/business-model-canvas-examples) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/startup-canvas/agents/openai.yaml b/skills/startup-canvas/agents/openai.yaml deleted file mode 100644 index 9632f549..00000000 --- a/skills/startup-canvas/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Startup Canvas" - short_description: "Startup Canvas. Use when evaluating a startup concept or new product that needs product strategy and business model..." - brand_color: "#0F766E" - default_prompt: "Use $startup-canvas with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/startup-canvas/productize.json b/skills/startup-canvas/productize.json deleted file mode 100644 index 08d09933..00000000 --- a/skills/startup-canvas/productize.json +++ /dev/null @@ -1,50 +0,0 @@ -{ - "title": "Startup Canvas", - "category": "Venture / 0-1", - "lifecycle": "Think", - "tags": [ - "startup-canvas", - "0-to-1", - "business-model", - "product-strategy", - "founder", - "strategize", - "startup", - "canvas", - "venture", - "use", - "evaluating" - ], - "use_when": "Use when evaluating a startup concept or new product that needs product strategy and business model logic in one founder-ready artifact.", - "do_not_use_when": "Do not use for a narrow Lean Canvas, mature-company strategy memo, or execution plan after the concept is already validated.", - "output_artifact": "Startup Canvas combining product strategy, business model, risks, and next validation steps", - "routing_signals": [ - "startup-canvas", - "0-to-1", - "business-model", - "product-strategy", - "founder", - "when", - "evaluating", - "startup", - "concept", - "product", - "that", - "needs", - "strategy", - "business" - ], - "framework_fit": "Best for founders and 0-to-1 teams that need one artifact connecting customer, problem, solution, growth, economics, and assumptions.", - "failure_modes": [ - "Produces Startup Canvas combining product strategy, business model, risks, and next validation steps without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Startup Canvas as generic Venture / 0-1 advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Startup Canvas when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $startup-canvas to turn this 0-to-1 context into a decision-ready Startup Canvas combining product strategy, business model, risks, and next validation steps.", - "expected_artifact": "Startup Canvas combining product strategy, business model, risks, and next validation steps" - } - ], - "imported_from": "pm-skills-main/pm-product-strategy/skills/startup-canvas/SKILL.md" -} diff --git a/skills/statistical-analysis/SKILL.md b/skills/statistical-analysis/SKILL.md deleted file mode 100644 index f168ddad..00000000 --- a/skills/statistical-analysis/SKILL.md +++ /dev/null @@ -1,247 +0,0 @@ ---- -name: statistical-analysis -description: >- - Apply statistical methods including descriptive stats, trend analysis, outlier detection, and - hypothesis testing. Use when analyzing distributions, testing significance, detecting anomalies, - computing correlations, or interpreting statistical results. ---- - - - -# Statistical Analysis - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `statistical-analysis` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Statistical Analysis analytics diagnosis with metric readout, caveats, decision, and next instrumented step - -Helper skill for descriptive statistics, trends, outliers, hypothesis testing, and caution around statistical claims. - -## Invocation - -This is primarily a support skill for `analyze`, `explore-data`, `metrics-review`, `create-viz`, and `build-dashboard`. Use it explicitly when statistical method selection or interpretation matters. - -## Descriptive Statistics - -Choose the right center: - -| Situation | Use | Why | -|---|---|---| -| Symmetric distribution, no outliers | Mean | Efficient estimator | -| Skewed distribution | Median | Robust to outliers | -| Categorical or ordinal data | Mode | Only option for non-numeric | -| Highly skewed business metric | Median + mean | The gap shows skew | - -Always report mean and median together for business metrics. If they diverge meaningfully, the mean alone is misleading. - -Measure spread: -- Standard deviation: use with roughly normal data. -- IQR: robust to outliers; use with skewed data. -- Coefficient of variation: standard deviation divided by mean; useful across different scales. -- Range: quick extent, but highly outlier-sensitive. - -Use percentiles for business context: -- p1: floor or bottom 1 percent. -- p5: low end of normal. -- p25: first quartile. -- p50: median. -- p75: third quartile. -- p90: power-user threshold. -- p95: high end of normal. -- p99: extreme users or values. - -Characterize every numeric distribution by shape, center, spread, outliers, and natural bounds. - -## Trend Analysis - -Use moving averages to smooth noise: - -```python -df["ma_7d"] = df["metric"].rolling(window=7, min_periods=1).mean() -df["ma_28d"] = df["metric"].rolling(window=28, min_periods=1).mean() -``` - -Use period comparisons deliberately: -- Week over week: same day last week. -- Month over month: prior month. -- Year over year: best for seasonal businesses. -- Same-day-last-year: useful for calendar-day effects. - -Growth rates: - -```text -Simple growth = (current - previous) / previous -CAGR = (ending / beginning) ^ (1 / years) - 1 -Log growth = ln(current / previous) -``` - -Check seasonality before declaring a trend: -1. Plot raw time series. -2. Compare day-of-week averages. -3. Compare month-of-year averages. -4. Prefer YoY or same-period comparisons when seasonality is present. - -For lightweight forecasts, use naive, seasonal naive, linear trend, or moving-average forecasts. Always communicate a range, not false precision. - -Escalate to a data scientist when the trend is non-linear, has multiple seasonalities, depends on external drivers, or forecast accuracy drives resource allocation. - -## Outliers and Anomalies - -Use the right method: - -```python -# Z-score: use for approximately normal data -z_scores = (df["value"] - df["value"].mean()) / df["value"].std() -outliers = df[abs(z_scores) > 3] - -# IQR: robust for skewed data -q1 = df["value"].quantile(0.25) -q3 = df["value"].quantile(0.75) -iqr = q3 - q1 -lower = q1 - 1.5 * iqr -upper = q3 + 1.5 * iqr -outliers = df[(df["value"] < lower) | (df["value"] > upper)] - -# Percentile: simple boundary method -outliers = df[ - (df["value"] < df["value"].quantile(0.01)) | - (df["value"] > df["value"].quantile(0.99)) -] -``` - -Do not automatically remove outliers: -1. Investigate whether they are errors, real extremes, or another population. -2. Fix or remove true data errors. -3. Keep genuine extremes but use robust statistics when appropriate. -4. Segment different populations rather than averaging them together. - -For time series anomalies: -1. Compute expected value using moving average or same-period history. -2. Compute deviation from expected. -3. Flag deviations beyond 2-3 standard deviations of residuals. -4. Distinguish point anomalies from sustained change points. - -Always report how outliers were handled. - -## Hypothesis Testing - -Use hypothesis testing when deciding whether an observed difference could be due to chance: -- A/B test results. -- Before/after comparisons. -- Segment comparisons. - -Framework: -1. Define null hypothesis: no difference. -2. Define alternative hypothesis: there is a difference. -3. Choose alpha, usually 0.05. -4. Compute test statistic and p-value. -5. If p < alpha, reject the null. - -Common tests: - -| Scenario | Test | Use when | -|---|---|---| -| Two group means | Independent t-test | Normal data, two groups | -| Two proportions | Z-test for proportions | Conversion or binary outcomes | -| Paired measurements | Paired t-test | Before/after on same entities | -| Three or more means | ANOVA | Multiple segments or variants | -| Non-normal two groups | Mann-Whitney U | Skewed or ordinal data | -| Categorical association | Chi-squared | Two categorical variables | - -Always separate statistical significance from practical significance. Report: -- Effect size. -- Confidence interval. -- Business impact. -- Sample size and power caveats. - -Rule of thumb: for proportions, require at least 30 events per group for basic reliability. Small samples need explicit caution. - -## Statistical Cautions - -### Correlation Is Not Causation - -When reporting correlation, consider reverse causation, confounders, and coincidence. - -Say: "Users who use feature X have 30 percent higher retention." - -Do not say without stronger evidence: "Feature X causes 30 percent higher retention." - -### Multiple Comparisons - -If many metrics or segments were tested, some significant results will appear by chance. Note how many tests were run and consider Bonferroni correction or other multiple-testing controls. - -### Simpson's Paradox - -Aggregated trends can reverse after segmentation. Check whether the conclusion holds across key segments before acting. - -### Survivorship Bias - -Ask who is missing from the dataset. Active-user-only analyses exclude churned users and can overstate product health. - -### Ecological Fallacy - -Do not apply aggregate group trends to individuals without individual-level evidence. - -### False Precision - -Round to match uncertainty. Prefer "about 5 percent" or "4-6 percent" over "4.73 percent" when the latter implies unjustified certainty. - -## Output Rules - -- State the method used and why. -- State assumptions and sample limitations. -- Prefer ranges and confidence intervals over point estimates when uncertainty matters. -- Explain results in business language without overstating causality. diff --git a/skills/statistical-analysis/SKILL.md.tmpl b/skills/statistical-analysis/SKILL.md.tmpl deleted file mode 100644 index a9ca0c83..00000000 --- a/skills/statistical-analysis/SKILL.md.tmpl +++ /dev/null @@ -1,188 +0,0 @@ ---- -name: statistical-analysis -description: >- - Apply statistical methods including descriptive stats, trend analysis, outlier detection, and - hypothesis testing. Use when analyzing distributions, testing significance, detecting anomalies, - computing correlations, or interpreting statistical results. ---- -# Statistical Analysis - -{{PRODUCTIZE_PREAMBLE}} - -Helper skill for descriptive statistics, trends, outliers, hypothesis testing, and caution around statistical claims. - -## Invocation - -This is primarily a support skill for `analyze`, `explore-data`, `metrics-review`, `create-viz`, and `build-dashboard`. Use it explicitly when statistical method selection or interpretation matters. - -## Descriptive Statistics - -Choose the right center: - -| Situation | Use | Why | -|---|---|---| -| Symmetric distribution, no outliers | Mean | Efficient estimator | -| Skewed distribution | Median | Robust to outliers | -| Categorical or ordinal data | Mode | Only option for non-numeric | -| Highly skewed business metric | Median + mean | The gap shows skew | - -Always report mean and median together for business metrics. If they diverge meaningfully, the mean alone is misleading. - -Measure spread: -- Standard deviation: use with roughly normal data. -- IQR: robust to outliers; use with skewed data. -- Coefficient of variation: standard deviation divided by mean; useful across different scales. -- Range: quick extent, but highly outlier-sensitive. - -Use percentiles for business context: -- p1: floor or bottom 1 percent. -- p5: low end of normal. -- p25: first quartile. -- p50: median. -- p75: third quartile. -- p90: power-user threshold. -- p95: high end of normal. -- p99: extreme users or values. - -Characterize every numeric distribution by shape, center, spread, outliers, and natural bounds. - -## Trend Analysis - -Use moving averages to smooth noise: - -```python -df["ma_7d"] = df["metric"].rolling(window=7, min_periods=1).mean() -df["ma_28d"] = df["metric"].rolling(window=28, min_periods=1).mean() -``` - -Use period comparisons deliberately: -- Week over week: same day last week. -- Month over month: prior month. -- Year over year: best for seasonal businesses. -- Same-day-last-year: useful for calendar-day effects. - -Growth rates: - -```text -Simple growth = (current - previous) / previous -CAGR = (ending / beginning) ^ (1 / years) - 1 -Log growth = ln(current / previous) -``` - -Check seasonality before declaring a trend: -1. Plot raw time series. -2. Compare day-of-week averages. -3. Compare month-of-year averages. -4. Prefer YoY or same-period comparisons when seasonality is present. - -For lightweight forecasts, use naive, seasonal naive, linear trend, or moving-average forecasts. Always communicate a range, not false precision. - -Escalate to a data scientist when the trend is non-linear, has multiple seasonalities, depends on external drivers, or forecast accuracy drives resource allocation. - -## Outliers and Anomalies - -Use the right method: - -```python -# Z-score: use for approximately normal data -z_scores = (df["value"] - df["value"].mean()) / df["value"].std() -outliers = df[abs(z_scores) > 3] - -# IQR: robust for skewed data -q1 = df["value"].quantile(0.25) -q3 = df["value"].quantile(0.75) -iqr = q3 - q1 -lower = q1 - 1.5 * iqr -upper = q3 + 1.5 * iqr -outliers = df[(df["value"] < lower) | (df["value"] > upper)] - -# Percentile: simple boundary method -outliers = df[ - (df["value"] < df["value"].quantile(0.01)) | - (df["value"] > df["value"].quantile(0.99)) -] -``` - -Do not automatically remove outliers: -1. Investigate whether they are errors, real extremes, or another population. -2. Fix or remove true data errors. -3. Keep genuine extremes but use robust statistics when appropriate. -4. Segment different populations rather than averaging them together. - -For time series anomalies: -1. Compute expected value using moving average or same-period history. -2. Compute deviation from expected. -3. Flag deviations beyond 2-3 standard deviations of residuals. -4. Distinguish point anomalies from sustained change points. - -Always report how outliers were handled. - -## Hypothesis Testing - -Use hypothesis testing when deciding whether an observed difference could be due to chance: -- A/B test results. -- Before/after comparisons. -- Segment comparisons. - -Framework: -1. Define null hypothesis: no difference. -2. Define alternative hypothesis: there is a difference. -3. Choose alpha, usually 0.05. -4. Compute test statistic and p-value. -5. If p < alpha, reject the null. - -Common tests: - -| Scenario | Test | Use when | -|---|---|---| -| Two group means | Independent t-test | Normal data, two groups | -| Two proportions | Z-test for proportions | Conversion or binary outcomes | -| Paired measurements | Paired t-test | Before/after on same entities | -| Three or more means | ANOVA | Multiple segments or variants | -| Non-normal two groups | Mann-Whitney U | Skewed or ordinal data | -| Categorical association | Chi-squared | Two categorical variables | - -Always separate statistical significance from practical significance. Report: -- Effect size. -- Confidence interval. -- Business impact. -- Sample size and power caveats. - -Rule of thumb: for proportions, require at least 30 events per group for basic reliability. Small samples need explicit caution. - -## Statistical Cautions - -### Correlation Is Not Causation - -When reporting correlation, consider reverse causation, confounders, and coincidence. - -Say: "Users who use feature X have 30 percent higher retention." - -Do not say without stronger evidence: "Feature X causes 30 percent higher retention." - -### Multiple Comparisons - -If many metrics or segments were tested, some significant results will appear by chance. Note how many tests were run and consider Bonferroni correction or other multiple-testing controls. - -### Simpson's Paradox - -Aggregated trends can reverse after segmentation. Check whether the conclusion holds across key segments before acting. - -### Survivorship Bias - -Ask who is missing from the dataset. Active-user-only analyses exclude churned users and can overstate product health. - -### Ecological Fallacy - -Do not apply aggregate group trends to individuals without individual-level evidence. - -### False Precision - -Round to match uncertainty. Prefer "about 5 percent" or "4-6 percent" over "4.73 percent" when the latter implies unjustified certainty. - -## Output Rules - -- State the method used and why. -- State assumptions and sample limitations. -- Prefer ranges and confidence intervals over point estimates when uncertainty matters. -- Explain results in business language without overstating causality. diff --git a/skills/statistical-analysis/agents/openai.yaml b/skills/statistical-analysis/agents/openai.yaml deleted file mode 100644 index 12966596..00000000 --- a/skills/statistical-analysis/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Statistical Analysis" - short_description: "Apply statistical methods including descriptive stats, trend analysis, outlier detection, and hypothesis testing...." - brand_color: "#0F766E" - default_prompt: "Use $statistical-analysis with my product context." - -policy: - allow_implicit_invocation: false diff --git a/skills/statistical-analysis/productize.json b/skills/statistical-analysis/productize.json deleted file mode 100644 index 7e8fab60..00000000 --- a/skills/statistical-analysis/productize.json +++ /dev/null @@ -1,50 +0,0 @@ -{ - "title": "Statistical Analysis", - "category": "Analytics", - "allow_implicit_invocation": false, - "tags": [ - "statistics", - "hypothesis-testing", - "outliers", - "trend-analysis", - "correlation", - "anomaly-detection", - "statistical-analysis", - "statistical", - "data", - "reporting", - "apply", - "methods", - "including", - "descriptive" - ], - "lifecycle": "Measure", - "use_when": "Apply statistical methods including descriptive stats, trend analysis, outlier detection, and hypothesis testing. Use when analyzing distributions, testing significance, detecting anomalies, computing correlations, or interpreting statistical results.", - "do_not_use_when": "Do not use Statistical Analysis when the request is mainly early ideation, qualitative research, or roadmap writing without metrics; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Statistical Analysis analytics diagnosis with metric readout, caveats, decision, and next instrumented step", - "routing_signals": [ - "statistical-analysis", - "statistical", - "data", - "reporting", - "apply", - "methods", - "including", - "descriptive", - "stats", - "analytics", - "trend" - ], - "framework_fit": "Statistical Analysis fits Analytics work in the Measure lifecycle when the user needs Statistical Analysis analytics diagnosis with metric readout, caveats, decision, and next instrumented step and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Statistical Analysis analytics diagnosis with metric readout, caveats, decision, and next instrumented step without tying recommendations to the user's Measure stage, evidence, and decision pressure.", - "Treats Statistical Analysis as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Statistical Analysis when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $statistical-analysis to turn this statistical context into a decision-ready Statistical Analysis analytics diagnosis with metric readout, caveats, decision, and next instrumented step.", - "expected_artifact": "Statistical Analysis analytics diagnosis with metric readout, caveats, decision, and next instrumented step" - } - ] -} diff --git a/skills/strategic-crux-diagnosis-and-strategy-design/SKILL.md b/skills/strategic-crux-diagnosis-and-strategy-design/SKILL.md deleted file mode 100644 index 5bbedb12..00000000 --- a/skills/strategic-crux-diagnosis-and-strategy-design/SKILL.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -name: strategic-crux-diagnosis-and-strategy-design -description: >- - Strategic crux diagnosis and strategy design. Use when the user needs a product workflow for - product strategy related to strategic crux diagnosis and strategy design. Trigger terms: - strategy, decision-making, prioritization, product, leadership. ---- - - - -# Strategic crux diagnosis and strategy design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `strategic-crux-diagnosis-and-strategy-design` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Strategic crux diagnosis and strategy design strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Strategic crux diagnosis and strategy design**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONTEXT_SCOPE}} -- {{CURRENT_STATE}} -- {{DESIRED_FUTURE}} -- {{TIME_HORIZON}} -- {{CUSTOMERS_JTBD}} -- {{UVP_TODAY}} -- {{COMPETITIVE_LANDSCAPE}} -- {{KEY_CONSTRAINTS}} -- {{ASSETS_STRENGTHS}} -- {{RISKS_NON_NEGOTIABLES}} -- {{USER_INSIGHTS}} -- {{UNIT_ECONOMICS}} -- {{STAKEHOLDERS_DECISION_RIGHTS}} - - -GOAL -Produce a high-quality deliverable for: Strategic crux diagnosis and strategy design. -Success metric: -- Identifies the strategic crux with evidence-backed rationale. -- Proposes a leveraged strategy with explicit trade-offs and testable milestones. -- Provides a concrete execution plan with experiments, metrics, and risks. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if critical items are missing, ask up to 6 concise clarification questions first. -- Separate facts, assumptions, and inferences; label disconfirming evidence and uncertainties. -- Identify the crux and choose a leveraged strategy with explicit trade-offs. -- Provide options table, chosen strategy, 12โ€“18 week moves, experiments, metrics, risks, and resources. -- If constraints make the goal infeasible, propose renegotiations with quantified trade-offs. - -FORMAT -Return exactly this structure: - -1) Executive Summary (<=200 words) - -2) Strategic Narrative - -3) Evidence Pack - -4) Crux Definition - -5) Options & Trade-offs -| Option | Core Bet | Expected Impact (with math) | Cost (money/teams) | Time-to-First-Signal | Risks | Reversibility | Why It Might Fail | - -6) Chosen Strategy (Leverage Thesis) - -7) Strategic Moves (12โ€“18 weeks) -| Move | Owner | Start | End | Dependencies | Weekly Leading Indicator | Target | Risk & Mitigation | - -8) Experiments to Prove/Disprove - -9) Metrics & Monitoring - -10) Risks, Preconditions, and Constraint Renegotiations - -11) Resource Plan - -12) Decision Log & Next Checkpoint - -Appendices (tables) -1. Assumptions -> Tests Map: | Assumption | Test/Experiment | When | Owner | Decision Rule | -2. Roadmap (Quarter): | Week | Move | Deliverable | Confidence | -3. Stakeholder Map: | Stakeholder | Interest/Influence | What They Need to See | - -FAILURE -- Any required section/table in `FORMAT` is missing, malformed, or incomplete. -- Crux is not explicitly defined or not tied to evidence. -- Options table is missing or lacks required columns. -- Moves lack owners, timeline, or leading indicators. -- Experiments lack hypothesis/metrics or stop/scale rules. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategic-crux-diagnosis-and-strategy-design/SKILL.md.tmpl b/skills/strategic-crux-diagnosis-and-strategy-design/SKILL.md.tmpl deleted file mode 100644 index 5dfc063d..00000000 --- a/skills/strategic-crux-diagnosis-and-strategy-design/SKILL.md.tmpl +++ /dev/null @@ -1,97 +0,0 @@ ---- -name: strategic-crux-diagnosis-and-strategy-design -description: >- - Strategic crux diagnosis and strategy design. Use when the user needs a product workflow for - product strategy related to strategic crux diagnosis and strategy design. Trigger terms: - strategy, decision-making, prioritization, product, leadership. ---- -# Strategic crux diagnosis and strategy design - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Strategic crux diagnosis and strategy design**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONTEXT_SCOPE}} -- {{CURRENT_STATE}} -- {{DESIRED_FUTURE}} -- {{TIME_HORIZON}} -- {{CUSTOMERS_JTBD}} -- {{UVP_TODAY}} -- {{COMPETITIVE_LANDSCAPE}} -- {{KEY_CONSTRAINTS}} -- {{ASSETS_STRENGTHS}} -- {{RISKS_NON_NEGOTIABLES}} -- {{USER_INSIGHTS}} -- {{UNIT_ECONOMICS}} -- {{STAKEHOLDERS_DECISION_RIGHTS}} - - -GOAL -Produce a high-quality deliverable for: Strategic crux diagnosis and strategy design. -Success metric: -- Identifies the strategic crux with evidence-backed rationale. -- Proposes a leveraged strategy with explicit trade-offs and testable milestones. -- Provides a concrete execution plan with experiments, metrics, and risks. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if critical items are missing, ask up to 6 concise clarification questions first. -- Separate facts, assumptions, and inferences; label disconfirming evidence and uncertainties. -- Identify the crux and choose a leveraged strategy with explicit trade-offs. -- Provide options table, chosen strategy, 12โ€“18 week moves, experiments, metrics, risks, and resources. -- If constraints make the goal infeasible, propose renegotiations with quantified trade-offs. - -FORMAT -Return exactly this structure: - -1) Executive Summary (<=200 words) - -2) Strategic Narrative - -3) Evidence Pack - -4) Crux Definition - -5) Options & Trade-offs -| Option | Core Bet | Expected Impact (with math) | Cost (money/teams) | Time-to-First-Signal | Risks | Reversibility | Why It Might Fail | - -6) Chosen Strategy (Leverage Thesis) - -7) Strategic Moves (12โ€“18 weeks) -| Move | Owner | Start | End | Dependencies | Weekly Leading Indicator | Target | Risk & Mitigation | - -8) Experiments to Prove/Disprove - -9) Metrics & Monitoring - -10) Risks, Preconditions, and Constraint Renegotiations - -11) Resource Plan - -12) Decision Log & Next Checkpoint - -Appendices (tables) -1. Assumptions -> Tests Map: | Assumption | Test/Experiment | When | Owner | Decision Rule | -2. Roadmap (Quarter): | Week | Move | Deliverable | Confidence | -3. Stakeholder Map: | Stakeholder | Interest/Influence | What They Need to See | - -FAILURE -- Any required section/table in `FORMAT` is missing, malformed, or incomplete. -- Crux is not explicitly defined or not tied to evidence. -- Options table is missing or lacks required columns. -- Moves lack owners, timeline, or leading indicators. -- Experiments lack hypothesis/metrics or stop/scale rules. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategic-crux-diagnosis-and-strategy-design/agents/openai.yaml b/skills/strategic-crux-diagnosis-and-strategy-design/agents/openai.yaml deleted file mode 100644 index 50d05476..00000000 --- a/skills/strategic-crux-diagnosis-and-strategy-design/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Strategic crux diagnosis and strategy design" - short_description: "Strategic crux diagnosis and strategy design. Use when the user needs a product workflow for product strategy..." - brand_color: "#059669" - default_prompt: "Use $strategic-crux-diagnosis-and-strategy-design with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/strategic-crux-diagnosis-and-strategy-design/productize.json b/skills/strategic-crux-diagnosis-and-strategy-design/productize.json deleted file mode 100644 index 084bf23a..00000000 --- a/skills/strategic-crux-diagnosis-and-strategy-design/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Strategic crux diagnosis and strategy design", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "strategic-crux-diagnosis-and-strategy-design", - "strategic", - "crux", - "diagnosis", - "design" - ], - "use_when": "Strategic crux diagnosis and strategy design. Use when the user needs a product workflow for product strategy related to strategic crux diagnosis and strategy design. Trigger terms: strategy, decision-making, prioritization, product, leadership.", - "do_not_use_when": "Do not use Strategic crux diagnosis and strategy design when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Strategic crux diagnosis and strategy design strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "strategic-crux-diagnosis-and-strategy-design", - "strategic", - "crux", - "diagnosis", - "design" - ], - "framework_fit": "Strategic crux diagnosis and strategy design fits Strategy work in the Strategize lifecycle when the user needs Strategic crux diagnosis and strategy design strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Strategic crux diagnosis and strategy design strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Strategic crux diagnosis and strategy design as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Strategic crux diagnosis and strategy design when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $strategic-crux-diagnosis-and-strategy-design to turn this strategic context into a decision-ready Strategic crux diagnosis and strategy design strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Strategic crux diagnosis and strategy design strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/strategic-decision-making-quality-review/SKILL.md b/skills/strategic-decision-making-quality-review/SKILL.md deleted file mode 100644 index 6c3078a9..00000000 --- a/skills/strategic-decision-making-quality-review/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: strategic-decision-making-quality-review -description: >- - Review the quality of a strategic product, innovation, or operating decision. Use when - the user needs a decision-making artifact that separates facts, assumptions, alternatives, - bias risks, evidence gaps, and decision safeguards before choosing. ---- - - - -# Strategic Decision Making Quality Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `strategic-decision-making-quality-review` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Strategic decision quality review with decision frame, evidence map, option audit, bias risks, safeguards, and recommendation - -Use this skill when the work is explicitly about improving a decision, not producing a -generic strategy memo. It is for strategic product, innovation, market-entry, roadmap, -investment, pivot, kill/continue, or executive operating decisions. - -Do not use this skill when the user needs only a personal gut check, a decision-rights -RACI/DAVCI map, an A/B test readout, a narrow pre-mortem, or a stakeholder narrative. -Route those to the narrower Productize skill. - -## Decision-Making Principles - -- Treat decisions as experiments with incomplete information and often only one execution chance. -- Separate rational-choice assumptions from real decision-maker constraints: bounded rationality, - imperfect information, overload, satisficing, unstable preferences, and future uncertainty. -- Identify when System 1 intuition is helpful pattern recognition and when it is unreliable. -- Use System 2 deliberately for irreversible, high-stakes, unfamiliar, or multi-factor decisions. -- Identify the decision context before applying tools: VUCA, noisy/dynamic innovation, - stable market, time-sensitive, group-influenced, or politically loaded. -- Review common decision traps: base-rate neglect, representativeness, availability, - anchoring, framing, confirmation, sunk cost, status quo, optimism, loss/risk aversion, - and escalation of commitment. -- Improve decision quality with opposite-case reasoning, alternative hypotheses, stress tests, - root-cause analysis, disconfirming evidence, base rates, explicit thresholds, and review loops. - -## Workflow - -1. Define the decision, owner, stakes, reversibility, deadline, and required artifact. -2. Separate facts, assumptions, unknowns, constraints, and subjective thresholds. -3. Identify candidate options and the implicit anchor or default option. -4. Audit bias and heuristic risks in the current framing. -5. Add base rates, counter-evidence, alternative hypotheses, and root-cause checks. -6. Create decision criteria and thresholds before recommending. -7. Recommend, defer, test, or ask for a blocking input. -8. Record what would change the decision later. - -## Output Contract - -Return: - -```markdown -# Strategic Decision Making Quality Review - -## 1. Decision Frame -Decision: -Decision owner: -Deadline: -Stakes: -Reversibility: -Context type: - -## 2. Known / Assumed / Missing / Risky -Known facts: -Assumptions: -Missing evidence: -Risky leaps: - -## 3. Options And Default Anchor -Option A: -Option B: -Option C: -Current default or anchor: -Why the default may be sticky: - -## 4. Decision Trap Audit -Base-rate neglect: -Representativeness: -Availability: -Anchoring: -Framing / loss-gain presentation: -Confirmation: -Sunk cost / escalation: -Status quo: -Optimism: -Loss or risk aversion: - -## 5. Decision Safeguards -Opposite case: -Alternative hypotheses: -Disconfirming evidence to seek: -Root-cause check: -Thresholds before deciding: -Decision review date: - -## 6. Recommendation -Recommend / ask / defer / test: -Rationale: -Confidence: -What would change this decision: -Next action: -``` - -## Failure Modes - -- Produces a generic strategy recommendation without auditing decision process quality. -- Treats the user's first framing as neutral rather than checking anchors, losses, defaults, - and missing alternatives. -- Lists biases without connecting them to the specific decision and safeguards. -- Recommends before separating known facts, assumptions, missing evidence, and risky leaps. diff --git a/skills/strategic-decision-making-quality-review/SKILL.md.tmpl b/skills/strategic-decision-making-quality-review/SKILL.md.tmpl deleted file mode 100644 index c178a969..00000000 --- a/skills/strategic-decision-making-quality-review/SKILL.md.tmpl +++ /dev/null @@ -1,108 +0,0 @@ ---- -name: strategic-decision-making-quality-review -description: >- - Review the quality of a strategic product, innovation, or operating decision. Use when - the user needs a decision-making artifact that separates facts, assumptions, alternatives, - bias risks, evidence gaps, and decision safeguards before choosing. ---- -# Strategic Decision Making Quality Review - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when the work is explicitly about improving a decision, not producing a -generic strategy memo. It is for strategic product, innovation, market-entry, roadmap, -investment, pivot, kill/continue, or executive operating decisions. - -Do not use this skill when the user needs only a personal gut check, a decision-rights -RACI/DAVCI map, an A/B test readout, a narrow pre-mortem, or a stakeholder narrative. -Route those to the narrower Productize skill. - -## Decision-Making Principles - -- Treat decisions as experiments with incomplete information and often only one execution chance. -- Separate rational-choice assumptions from real decision-maker constraints: bounded rationality, - imperfect information, overload, satisficing, unstable preferences, and future uncertainty. -- Identify when System 1 intuition is helpful pattern recognition and when it is unreliable. -- Use System 2 deliberately for irreversible, high-stakes, unfamiliar, or multi-factor decisions. -- Identify the decision context before applying tools: VUCA, noisy/dynamic innovation, - stable market, time-sensitive, group-influenced, or politically loaded. -- Review common decision traps: base-rate neglect, representativeness, availability, - anchoring, framing, confirmation, sunk cost, status quo, optimism, loss/risk aversion, - and escalation of commitment. -- Improve decision quality with opposite-case reasoning, alternative hypotheses, stress tests, - root-cause analysis, disconfirming evidence, base rates, explicit thresholds, and review loops. - -## Workflow - -1. Define the decision, owner, stakes, reversibility, deadline, and required artifact. -2. Separate facts, assumptions, unknowns, constraints, and subjective thresholds. -3. Identify candidate options and the implicit anchor or default option. -4. Audit bias and heuristic risks in the current framing. -5. Add base rates, counter-evidence, alternative hypotheses, and root-cause checks. -6. Create decision criteria and thresholds before recommending. -7. Recommend, defer, test, or ask for a blocking input. -8. Record what would change the decision later. - -## Output Contract - -Return: - -```markdown -# Strategic Decision Making Quality Review - -## 1. Decision Frame -Decision: -Decision owner: -Deadline: -Stakes: -Reversibility: -Context type: - -## 2. Known / Assumed / Missing / Risky -Known facts: -Assumptions: -Missing evidence: -Risky leaps: - -## 3. Options And Default Anchor -Option A: -Option B: -Option C: -Current default or anchor: -Why the default may be sticky: - -## 4. Decision Trap Audit -Base-rate neglect: -Representativeness: -Availability: -Anchoring: -Framing / loss-gain presentation: -Confirmation: -Sunk cost / escalation: -Status quo: -Optimism: -Loss or risk aversion: - -## 5. Decision Safeguards -Opposite case: -Alternative hypotheses: -Disconfirming evidence to seek: -Root-cause check: -Thresholds before deciding: -Decision review date: - -## 6. Recommendation -Recommend / ask / defer / test: -Rationale: -Confidence: -What would change this decision: -Next action: -``` - -## Failure Modes - -- Produces a generic strategy recommendation without auditing decision process quality. -- Treats the user's first framing as neutral rather than checking anchors, losses, defaults, - and missing alternatives. -- Lists biases without connecting them to the specific decision and safeguards. -- Recommends before separating known facts, assumptions, missing evidence, and risky leaps. diff --git a/skills/strategic-decision-making-quality-review/agents/openai.yaml b/skills/strategic-decision-making-quality-review/agents/openai.yaml deleted file mode 100644 index b8aa76fc..00000000 --- a/skills/strategic-decision-making-quality-review/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Strategic Decision Making Quality Review" - short_description: "Review the quality of a strategic product, innovation, or operating decision. Use when the user needs a..." - brand_color: "#7C2D12" - default_prompt: "Use $strategic-decision-making-quality-review with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/strategic-decision-making-quality-review/productize.json b/skills/strategic-decision-making-quality-review/productize.json deleted file mode 100644 index 8808a0db..00000000 --- a/skills/strategic-decision-making-quality-review/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Strategic Decision Making Quality Review", - "category": "Decision Making", - "lifecycle": "Think", - "tags": [ - "strategic-decision-making", - "decision-quality", - "bias-review", - "heuristics", - "bounded-rationality", - "system-1-system-2", - "satisficing", - "base-rates", - "anchoring", - "confirmation-bias", - "sunk-cost", - "strategic-decision-making-quality-review", - "strategic", - "decision" - ], - "use_when": "Use when a product leader, founder, PM, or executive needs to improve the quality of a strategic product, innovation, market-entry, roadmap, pivot, investment, kill/continue, or operating decision before choosing.", - "do_not_use_when": "Do not use for personal gut-check coaching, formal decision-rights ownership, A/B test ship decisions, narrow launch risk reviews, or stakeholder comms; route those to the narrower Productize skill.", - "output_artifact": "Strategic decision quality review with decision frame, evidence map, option audit, bias risks, safeguards, and recommendation", - "routing_signals": [ - "strategic-decision-making", - "decision-quality", - "bias-review", - "heuristics", - "bounded-rationality", - "system-1", - "system-2", - "satisficing", - "base-rate", - "anchoring", - "confirmation-bias", - "sunk-cost", - "framing-effect", - "loss-aversion" - ], - "framework_fit": "Best when the main job is to improve how a strategic decision is framed, tested, and chosen under uncertainty.", - "failure_modes": [ - "Produces strategy advice without auditing decision-process risk.", - "Treats the first framing as neutral instead of checking anchors, defaults, and missing options.", - "Lists biases generically instead of mapping each risk to a concrete safeguard.", - "Recommends before separating known facts, assumptions, missing evidence, and risky leaps." - ], - "examples": [ - { - "prompt": "Use $strategic-decision-making-quality-review to review whether we should pivot our AI workflow product to enterprise buyers or keep targeting self-serve teams.", - "expected_artifact": "Strategic decision quality review with decision frame, evidence map, option audit, bias risks, safeguards, and recommendation" - } - ] -} diff --git a/skills/strategic-moves-from-swot-pairings/SKILL.md b/skills/strategic-moves-from-swot-pairings/SKILL.md deleted file mode 100644 index 4473b56a..00000000 --- a/skills/strategic-moves-from-swot-pairings/SKILL.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -name: strategic-moves-from-swot-pairings -description: >- - Strategic moves from SWOT pairings. Use when the user needs a product workflow for product - strategy related to strategic moves from swot pairings. Trigger terms: strategy, swot, - decision-making, structured-thinking. ---- - - - -# Strategic moves from SWOT pairings - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `strategic-moves-from-swot-pairings` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Strategic moves from SWOT pairings strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Strategic moves from SWOT pairings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SWOT_CONTEXT}} -- {{SWOT_STRENGTHS}} -- {{SWOT_WEAKNESSES}} -- {{SWOT_OPPORTUNITIES}} -- {{SWOT_THREATS}} - - -GOAL -Produce a high-quality deliverable for: Strategic moves from SWOT pairings. -Success metric: -- Produces strategic move patterns for all 6 SWOT pairings. -- Includes a combination matrix and 3โ€“7 unifying strategic themes. -- Keeps patterns general (not hyper-specific tactics) unless explicitly requested. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided SWOT inputs; if context is missing, ask a short set of clarification questions first. -- Generate patterns for all 6 SWOT pairings. -- Provide 5โ€“10 patterns per pairing, each with an optional trigger and a risk/assumption note. -- Include a combination matrix and 3โ€“7 strategic themes. -- Keep output general unless the user explicitly requests company-specific tactics. - -FORMAT -Return exactly this structure: - - -[If needed: ask up to 6 concise questions to obtain missing context and SWOT lists] - - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - - -[Lightweight matching rules across SWOT items] - - - -1. [Theme] -2. [Theme] -3. [Theme] -[Up to 7 themes] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any SWOT pairing has fewer than 5 or more than 10 patterns. -- Combination matrix or strategic themes are missing. -- Patterns are overly tactic-specific without request. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategic-moves-from-swot-pairings/SKILL.md.tmpl b/skills/strategic-moves-from-swot-pairings/SKILL.md.tmpl deleted file mode 100644 index 4d58daac..00000000 --- a/skills/strategic-moves-from-swot-pairings/SKILL.md.tmpl +++ /dev/null @@ -1,104 +0,0 @@ ---- -name: strategic-moves-from-swot-pairings -description: >- - Strategic moves from SWOT pairings. Use when the user needs a product workflow for product - strategy related to strategic moves from swot pairings. Trigger terms: strategy, swot, - decision-making, structured-thinking. ---- -# Strategic moves from SWOT pairings - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Strategic moves from SWOT pairings**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SWOT_CONTEXT}} -- {{SWOT_STRENGTHS}} -- {{SWOT_WEAKNESSES}} -- {{SWOT_OPPORTUNITIES}} -- {{SWOT_THREATS}} - - -GOAL -Produce a high-quality deliverable for: Strategic moves from SWOT pairings. -Success metric: -- Produces strategic move patterns for all 6 SWOT pairings. -- Includes a combination matrix and 3โ€“7 unifying strategic themes. -- Keeps patterns general (not hyper-specific tactics) unless explicitly requested. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided SWOT inputs; if context is missing, ask a short set of clarification questions first. -- Generate patterns for all 6 SWOT pairings. -- Provide 5โ€“10 patterns per pairing, each with an optional trigger and a risk/assumption note. -- Include a combination matrix and 3โ€“7 strategic themes. -- Keep output general unless the user explicitly requests company-specific tactics. - -FORMAT -Return exactly this structure: - - -[If needed: ask up to 6 concise questions to obtain missing context and SWOT lists] - - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - -1. [Pattern] - Trigger: [If/then] - Risk/Assumption: [Note] -... - - - - -[Lightweight matching rules across SWOT items] - - - -1. [Theme] -2. [Theme] -3. [Theme] -[Up to 7 themes] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Any SWOT pairing has fewer than 5 or more than 10 patterns. -- Combination matrix or strategic themes are missing. -- Patterns are overly tactic-specific without request. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategic-moves-from-swot-pairings/agents/openai.yaml b/skills/strategic-moves-from-swot-pairings/agents/openai.yaml deleted file mode 100644 index 951248c9..00000000 --- a/skills/strategic-moves-from-swot-pairings/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Strategic moves from SWOT pairings" - short_description: "Strategic moves from SWOT pairings. Use when the user needs a product workflow for product strategy related to..." - brand_color: "#059669" - default_prompt: "Use $strategic-moves-from-swot-pairings with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/strategic-moves-from-swot-pairings/productize.json b/skills/strategic-moves-from-swot-pairings/productize.json deleted file mode 100644 index 28b70b72..00000000 --- a/skills/strategic-moves-from-swot-pairings/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Strategic moves from SWOT pairings", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "strategic-moves-from-swot-pairings", - "strategic", - "moves", - "swot", - "pairings" - ], - "use_when": "Strategic moves from SWOT pairings. Use when the user needs a product workflow for product strategy related to strategic moves from swot pairings. Trigger terms: strategy, swot, decision-making, structured-thinking.", - "do_not_use_when": "Do not use Strategic moves from SWOT pairings when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Strategic moves from SWOT pairings strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "strategic-moves-from-swot-pairings", - "strategic", - "moves", - "swot", - "pairings" - ], - "framework_fit": "Strategic moves from SWOT pairings fits Strategy work in the Strategize lifecycle when the user needs Strategic moves from SWOT pairings strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Strategic moves from SWOT pairings strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Strategic moves from SWOT pairings as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Strategic moves from SWOT pairings when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $strategic-moves-from-swot-pairings to turn this strategic context into a decision-ready Strategic moves from SWOT pairings strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Strategic moves from SWOT pairings strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/strategic-presentation-planning-from-topic-audience-and-time/SKILL.md b/skills/strategic-presentation-planning-from-topic-audience-and-time/SKILL.md deleted file mode 100644 index 02da0e8a..00000000 --- a/skills/strategic-presentation-planning-from-topic-audience-and-time/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: strategic-presentation-planning-from-topic-audience-and-time -description: >- - Strategic presentation planning from topic, audience and time inputs. Use when the user - needs a product workflow for presentation & communication related to strategic presentation - planning from topic, audience and time inputs. Trigger terms: presentations, storytelling, - stakeholder-management, strategy. ---- - - - -# Strategic presentation planning from topic, audience and time inputs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `strategic-presentation-planning-from-topic-audience-and-time` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Strategic presentation planning from topic, audience and time inputs stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Strategic presentation planning from topic, audience and time inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRESENTATION_TOPIC}} -- {{TARGET_AUDIENCE}} -- {{TIME_CONSTRAINT}} - - -GOAL -Produce a high-quality deliverable for: Strategic presentation planning from topic, audience and time inputs. -Success metric: -- Produces a complete presentation framework tailored to topic, audience, and time constraint. -- Includes a concrete audience matrix, SCQA narrative, and pyramid logic with supporting evidence needs. -- Provides slide layout guidance and delivery preparation tuned to the audience. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRESENTATION_TOPIC}}`, `{{TARGET_AUDIENCE}}`, and `{{TIME_CONSTRAINT}}`; if context is missing, state assumptions explicitly. -- Build a strategic foundation with a detailed audience matrix and explicit purpose/decision criteria. -- Use SCQA for narrative framing and pyramid logic for justification structure. -- Provide slide layout strategy tied to content types and time constraint. -- Include QA checks and delivery preparation tailored to audience and time. - -FORMAT -Return exactly this structure: - - -1. Strategic Foundation - [Include your audience analysis and presentation purpose definition] - -2. Narrative Architecture - [Present your SCQA framework and Pyramid Principle structure] - -3. Slide Development - [Outline your slide selection strategy and design principles] - -4. Quality Assurance - [List key points for review] - -5. Preparation & Delivery - [Provide notes on content mastery and delivery adaptation] - - -FAILURE -- Any required numbered section in `FORMAT` is missing, malformed, or incomplete. -- Audience analysis lacks a matrix across power, expertise, bias, history, style, and politics. -- SCQA or pyramid logic is missing or not tied to the topic. -- Slide development guidance does not reflect time constraint or content type. -- QA checks are missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategic-presentation-planning-from-topic-audience-and-time/SKILL.md.tmpl b/skills/strategic-presentation-planning-from-topic-audience-and-time/SKILL.md.tmpl deleted file mode 100644 index 46d31e31..00000000 --- a/skills/strategic-presentation-planning-from-topic-audience-and-time/SKILL.md.tmpl +++ /dev/null @@ -1,74 +0,0 @@ ---- -name: strategic-presentation-planning-from-topic-audience-and-time -description: >- - Strategic presentation planning from topic, audience and time inputs. Use when the user - needs a product workflow for presentation & communication related to strategic presentation - planning from topic, audience and time inputs. Trigger terms: presentations, storytelling, - stakeholder-management, strategy. ---- -# Strategic presentation planning from topic, audience and time inputs - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Strategic presentation planning from topic, audience and time inputs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRESENTATION_TOPIC}} -- {{TARGET_AUDIENCE}} -- {{TIME_CONSTRAINT}} - - -GOAL -Produce a high-quality deliverable for: Strategic presentation planning from topic, audience and time inputs. -Success metric: -- Produces a complete presentation framework tailored to topic, audience, and time constraint. -- Includes a concrete audience matrix, SCQA narrative, and pyramid logic with supporting evidence needs. -- Provides slide layout guidance and delivery preparation tuned to the audience. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRESENTATION_TOPIC}}`, `{{TARGET_AUDIENCE}}`, and `{{TIME_CONSTRAINT}}`; if context is missing, state assumptions explicitly. -- Build a strategic foundation with a detailed audience matrix and explicit purpose/decision criteria. -- Use SCQA for narrative framing and pyramid logic for justification structure. -- Provide slide layout strategy tied to content types and time constraint. -- Include QA checks and delivery preparation tailored to audience and time. - -FORMAT -Return exactly this structure: - - -1. Strategic Foundation - [Include your audience analysis and presentation purpose definition] - -2. Narrative Architecture - [Present your SCQA framework and Pyramid Principle structure] - -3. Slide Development - [Outline your slide selection strategy and design principles] - -4. Quality Assurance - [List key points for review] - -5. Preparation & Delivery - [Provide notes on content mastery and delivery adaptation] - - -FAILURE -- Any required numbered section in `FORMAT` is missing, malformed, or incomplete. -- Audience analysis lacks a matrix across power, expertise, bias, history, style, and politics. -- SCQA or pyramid logic is missing or not tied to the topic. -- Slide development guidance does not reflect time constraint or content type. -- QA checks are missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategic-presentation-planning-from-topic-audience-and-time/agents/openai.yaml b/skills/strategic-presentation-planning-from-topic-audience-and-time/agents/openai.yaml deleted file mode 100644 index 66d212cb..00000000 --- a/skills/strategic-presentation-planning-from-topic-audience-and-time/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Strategic presentation planning from topic, audience and time inputs" - short_description: "Strategic presentation planning from topic, audience and time inputs. Use when the user needs a product workflow for..." - brand_color: "#0891B2" - default_prompt: "Use $strategic-presentation-planning-from-topic-audience-and-time with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/strategic-presentation-planning-from-topic-audience-and-time/productize.json b/skills/strategic-presentation-planning-from-topic-audience-and-time/productize.json deleted file mode 100644 index 12ffe53f..00000000 --- a/skills/strategic-presentation-planning-from-topic-audience-and-time/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Strategic presentation planning from topic, audience and time inputs", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "strategic-presentation-planning-from-topic-audience-and-time", - "strategic", - "presentation", - "planning", - "topic", - "audience", - "time" - ], - "use_when": "Strategic presentation planning from topic, audience and time inputs. Use when the user needs a product workflow for presentation & communication related to strategic presentation planning from topic, audience and time inputs. Trigger terms: presentations, storytelling, stakeholder-management, strategy.", - "do_not_use_when": "Do not use Strategic presentation planning from topic, audience and time inputs when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Strategic presentation planning from topic, audience and time inputs stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "strategic-presentation-planning-from-topic-audience-and-time", - "strategic", - "presentation", - "planning", - "topic", - "audience", - "time" - ], - "framework_fit": "Strategic presentation planning from topic, audience and time inputs fits Stakeholder Communication work in the Align lifecycle when the user needs Strategic presentation planning from topic, audience and time inputs stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Strategic presentation planning from topic, audience and time inputs stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Strategic presentation planning from topic, audience and time inputs as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Strategic presentation planning from topic, audience and time inputs when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $strategic-presentation-planning-from-topic-audience-and-time to turn this strategic context into a decision-ready Strategic presentation planning from topic, audience and time inputs stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Strategic presentation planning from topic, audience and time inputs stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/strategy-curve-blue-ocean/SKILL.md b/skills/strategy-curve-blue-ocean/SKILL.md deleted file mode 100644 index 51dd1c2c..00000000 --- a/skills/strategy-curve-blue-ocean/SKILL.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -name: strategy-curve-blue-ocean -description: >- - Apply strategy curve and blue ocean analysis to compare an offer against competitors, - identify factors of competition, plot as-is and to-be value curves, and define - breakaway moves. Use for marketing strategy, category redesign, differentiation, - noncustomer demand creation, and competitor value-curve analysis. ---- - - - -# Strategy Curve and Blue Ocean - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `strategy-curve-blue-ocean` -- **Lifecycle**: Strategize -- **Category**: Marketing -- **Primary artifact**: Strategy Curve and Blue Ocean strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill when the user needs to redesign an offer, category, or go-to-market strategy by changing the basis of competition. - -Do not use it for generic competitor lists, positioning copy only, brand voice, or growth funnel diagnosis unless the user also needs a value-curve comparison. - -## Inputs - -Collect or infer: - -- Industry/category and geography. -- Target customer or noncustomer group. -- Main competitors or strategic groups. -- Current offer and intended offer. -- Known customer frustrations, unmet outcomes, or barriers to adoption. -- Evidence: interviews, reviews, sales notes, market data, pricing, feature tables, usage data. - -If evidence is thin, label the analysis as hypothesis-driven. - -## Workflow - -1. **Define the arena** - - State the current red-ocean category and the buyer/noncustomer group being analyzed. - - Name strategic groups separately when the market has clusters such as premium, budget, self-serve, enterprise, incumbent, or substitute. - -2. **List factors of competition** - - Use buyer-facing factors, not internal capabilities. - - Include price/cost, access, product performance, service, experience, complexity, risk, status, convenience, trust, switching cost, and any category-specific factors. - - Remove factors that customers cannot perceive or that do not affect choice. - -3. **Plot the as-is strategy curves** - - Score each factor on a consistent 0-5 or Low/Medium/High scale. - - Plot the current offer and major competitors. - - Highlight convergence, overinvestment, underinvestment, and factors that serve legacy assumptions more than customer value. - -4. **Find blue-ocean openings** - - Ask where noncustomers are blocked by complexity, intimidation, cost, access, risk, or status codes. - - Identify where demand could be created rather than fought over. - - Look for factors the industry treats as mandatory but customers do not actually value. - -5. **Design the to-be value curve** - - Use the four actions: - - Eliminate: factors the industry takes for granted that can disappear. - - Reduce: factors over-served relative to customer value. - - Raise: factors that matter but are under-served. - - Create: new factors that unlock demand, trust, access, simplicity, or delight. - - The to-be curve should be visibly different, not just slightly better everywhere. - -6. **Translate into strategic moves** - - Name the projects required to close the gap. - - Define what must change in product, pricing, channel, service model, communication, and operations. - - Identify risks, capabilities needed, and proof points to test first. - -## Output - -Return: - -- **Strategic Arena**: category, target customer/noncustomer, competitors. -- **Factors of Competition**: table with factor definitions and why each matters. -- **As-Is Curves**: table of scores for current offer and competitors. -- **Red-Ocean Diagnosis**: where the market converges and where value is wasted. -- **Blue-Ocean Hypothesis**: the new demand or noncustomer unlock. -- **Eliminate/Reduce/Raise/Create**: table with rationale and evidence. -- **To-Be Curve**: target scores and the strategic pattern. -- **Strategic Projects**: actions, owners if known, dependencies, first proof point. -- **Risks and Tests**: assumptions that must be validated before scaling. - -## Quality Bar - -- Do not recommend being better at everything. -- Tie every factor to buyer behavior or noncustomer barriers. -- Distinguish facts, assumptions, and inferences. -- Make the to-be curve coherent enough that trade-offs are visible. diff --git a/skills/strategy-curve-blue-ocean/SKILL.md.tmpl b/skills/strategy-curve-blue-ocean/SKILL.md.tmpl deleted file mode 100644 index b10cb72d..00000000 --- a/skills/strategy-curve-blue-ocean/SKILL.md.tmpl +++ /dev/null @@ -1,83 +0,0 @@ ---- -name: strategy-curve-blue-ocean -description: >- - Apply strategy curve and blue ocean analysis to compare an offer against competitors, - identify factors of competition, plot as-is and to-be value curves, and define - breakaway moves. Use for marketing strategy, category redesign, differentiation, - noncustomer demand creation, and competitor value-curve analysis. ---- -# Strategy Curve and Blue Ocean - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when the user needs to redesign an offer, category, or go-to-market strategy by changing the basis of competition. - -Do not use it for generic competitor lists, positioning copy only, brand voice, or growth funnel diagnosis unless the user also needs a value-curve comparison. - -## Inputs - -Collect or infer: - -- Industry/category and geography. -- Target customer or noncustomer group. -- Main competitors or strategic groups. -- Current offer and intended offer. -- Known customer frustrations, unmet outcomes, or barriers to adoption. -- Evidence: interviews, reviews, sales notes, market data, pricing, feature tables, usage data. - -If evidence is thin, label the analysis as hypothesis-driven. - -## Workflow - -1. **Define the arena** - - State the current red-ocean category and the buyer/noncustomer group being analyzed. - - Name strategic groups separately when the market has clusters such as premium, budget, self-serve, enterprise, incumbent, or substitute. - -2. **List factors of competition** - - Use buyer-facing factors, not internal capabilities. - - Include price/cost, access, product performance, service, experience, complexity, risk, status, convenience, trust, switching cost, and any category-specific factors. - - Remove factors that customers cannot perceive or that do not affect choice. - -3. **Plot the as-is strategy curves** - - Score each factor on a consistent 0-5 or Low/Medium/High scale. - - Plot the current offer and major competitors. - - Highlight convergence, overinvestment, underinvestment, and factors that serve legacy assumptions more than customer value. - -4. **Find blue-ocean openings** - - Ask where noncustomers are blocked by complexity, intimidation, cost, access, risk, or status codes. - - Identify where demand could be created rather than fought over. - - Look for factors the industry treats as mandatory but customers do not actually value. - -5. **Design the to-be value curve** - - Use the four actions: - - Eliminate: factors the industry takes for granted that can disappear. - - Reduce: factors over-served relative to customer value. - - Raise: factors that matter but are under-served. - - Create: new factors that unlock demand, trust, access, simplicity, or delight. - - The to-be curve should be visibly different, not just slightly better everywhere. - -6. **Translate into strategic moves** - - Name the projects required to close the gap. - - Define what must change in product, pricing, channel, service model, communication, and operations. - - Identify risks, capabilities needed, and proof points to test first. - -## Output - -Return: - -- **Strategic Arena**: category, target customer/noncustomer, competitors. -- **Factors of Competition**: table with factor definitions and why each matters. -- **As-Is Curves**: table of scores for current offer and competitors. -- **Red-Ocean Diagnosis**: where the market converges and where value is wasted. -- **Blue-Ocean Hypothesis**: the new demand or noncustomer unlock. -- **Eliminate/Reduce/Raise/Create**: table with rationale and evidence. -- **To-Be Curve**: target scores and the strategic pattern. -- **Strategic Projects**: actions, owners if known, dependencies, first proof point. -- **Risks and Tests**: assumptions that must be validated before scaling. - -## Quality Bar - -- Do not recommend being better at everything. -- Tie every factor to buyer behavior or noncustomer barriers. -- Distinguish facts, assumptions, and inferences. -- Make the to-be curve coherent enough that trade-offs are visible. diff --git a/skills/strategy-curve-blue-ocean/agents/openai.yaml b/skills/strategy-curve-blue-ocean/agents/openai.yaml deleted file mode 100644 index fbc23458..00000000 --- a/skills/strategy-curve-blue-ocean/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Strategy Curve and Blue Ocean" - short_description: "Apply strategy curve and blue ocean analysis to compare an offer against competitors, identify factors of..." - brand_color: "#EA580C" - default_prompt: "Use $strategy-curve-blue-ocean with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/strategy-curve-blue-ocean/productize.json b/skills/strategy-curve-blue-ocean/productize.json deleted file mode 100644 index 48e0375c..00000000 --- a/skills/strategy-curve-blue-ocean/productize.json +++ /dev/null @@ -1,43 +0,0 @@ -{ - "title": "Strategy Curve and Blue Ocean", - "category": "Marketing", - "tags": [ - "marketing-strategy", - "strategy-curve", - "blue-ocean", - "differentiation", - "competitive-strategy", - "value-curve", - "noncustomers", - "strategy-curve-blue-ocean", - "curve", - "blue", - "ocean", - "marketing", - "apply" - ], - "lifecycle": "Strategize", - "use_when": "Apply strategy curve and blue ocean analysis to compare an offer against competitors, identify factors of competition, plot as-is and to-be value curves, and define breakaway moves. Use for marketing strategy, category redesign, differentiation, noncustomer demand creation, and competitor value-curve analysis.", - "do_not_use_when": "Do not use Strategy Curve and Blue Ocean when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Strategy Curve and Blue Ocean strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "strategy-curve-blue-ocean", - "curve", - "blue", - "ocean", - "marketing", - "apply" - ], - "framework_fit": "Strategy Curve and Blue Ocean fits Marketing work in the Strategize lifecycle when the user needs Strategy Curve and Blue Ocean strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Strategy Curve and Blue Ocean strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Strategy Curve and Blue Ocean as generic Marketing advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Strategy Curve and Blue Ocean when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $strategy-curve-blue-ocean to turn this curve context into a decision-ready Strategy Curve and Blue Ocean strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Strategy Curve and Blue Ocean strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/strategy-kernel-extraction-from-context/SKILL.md b/skills/strategy-kernel-extraction-from-context/SKILL.md deleted file mode 100644 index 9b7f13f7..00000000 --- a/skills/strategy-kernel-extraction-from-context/SKILL.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -name: strategy-kernel-extraction-from-context -description: >- - Strategy Kernel extraction from context. Use when the user needs a product workflow for - product strategy related to strategy kernel extraction from context. Trigger terms: - strategy, product-management, diagnosis, context. ---- - - - -# Strategy Kernel extraction from context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `strategy-kernel-extraction-from-context` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Strategy Kernel extraction from context strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Strategy Kernel extraction from context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_MANAGER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Strategy Kernel extraction from context. -Success metric: -- Extracts explicit, implied, and missing strategic context with clear gaps and next steps. -- Flags risks/anti-patterns and prioritizes follow-up questions. -- Produces a structured assessment aligned to the Strategy Kernel Canvas sections. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_MANAGER_INPUT}}`; if key context is missing, state assumptions explicitly. -- Extract explicit, implied, and missing information across History, Diagnosis, and Guiding Policy. -- Flag anti-patterns when supported by the input. -- Provide 3โ€“5 prioritized clarification questions if critical gaps remain. -- Keep output structured and decision-ready; no fluff. - -FORMAT -Return exactly this structure: - -context_assessment: - completeness_score: [0-100] - confidence_level: [high/medium/low] - - explicit_information: - - [Clearly stated items] - - implied_information: - - [Reasonable inferences] - - critical_gaps: - - gap: [description] - why_critical: [explanation] - how_to_obtain: [suggested action] - - red_flags: - - [Potential derailers] - - recommended_focus_areas: - - [Where to focus effort] - - stakeholder_map: - - name/role: [name or role] - influence: [high/medium/low] - alignment: [aligned/neutral/opposed/unknown] - - next_steps: - immediate: - - [Next 24 hours] - week_one: - - [First week actions] - -clarifying_questions: - - "[CRITICAL] [Question] - Why this matters: [explanation]" - - "[IMPORTANT] [Question] - Why this matters: [explanation]" - - "[USEFUL] [Question] - Why this matters: [explanation]" - -FAILURE -- Output is missing `context_assessment` or `clarifying_questions`. -- Completeness score or confidence level is missing. -- Critical gaps are missing when evidence is insufficient. -- Clarifying questions are not prioritized or fewer than 3 when needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategy-kernel-extraction-from-context/SKILL.md.tmpl b/skills/strategy-kernel-extraction-from-context/SKILL.md.tmpl deleted file mode 100644 index db2fb860..00000000 --- a/skills/strategy-kernel-extraction-from-context/SKILL.md.tmpl +++ /dev/null @@ -1,90 +0,0 @@ ---- -name: strategy-kernel-extraction-from-context -description: >- - Strategy Kernel extraction from context. Use when the user needs a product workflow for - product strategy related to strategy kernel extraction from context. Trigger terms: - strategy, product-management, diagnosis, context. ---- -# Strategy Kernel extraction from context - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Strategy Kernel extraction from context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_MANAGER_INPUT}} - - -GOAL -Produce a high-quality deliverable for: Strategy Kernel extraction from context. -Success metric: -- Extracts explicit, implied, and missing strategic context with clear gaps and next steps. -- Flags risks/anti-patterns and prioritizes follow-up questions. -- Produces a structured assessment aligned to the Strategy Kernel Canvas sections. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_MANAGER_INPUT}}`; if key context is missing, state assumptions explicitly. -- Extract explicit, implied, and missing information across History, Diagnosis, and Guiding Policy. -- Flag anti-patterns when supported by the input. -- Provide 3โ€“5 prioritized clarification questions if critical gaps remain. -- Keep output structured and decision-ready; no fluff. - -FORMAT -Return exactly this structure: - -context_assessment: - completeness_score: [0-100] - confidence_level: [high/medium/low] - - explicit_information: - - [Clearly stated items] - - implied_information: - - [Reasonable inferences] - - critical_gaps: - - gap: [description] - why_critical: [explanation] - how_to_obtain: [suggested action] - - red_flags: - - [Potential derailers] - - recommended_focus_areas: - - [Where to focus effort] - - stakeholder_map: - - name/role: [name or role] - influence: [high/medium/low] - alignment: [aligned/neutral/opposed/unknown] - - next_steps: - immediate: - - [Next 24 hours] - week_one: - - [First week actions] - -clarifying_questions: - - "[CRITICAL] [Question] - Why this matters: [explanation]" - - "[IMPORTANT] [Question] - Why this matters: [explanation]" - - "[USEFUL] [Question] - Why this matters: [explanation]" - -FAILURE -- Output is missing `context_assessment` or `clarifying_questions`. -- Completeness score or confidence level is missing. -- Critical gaps are missing when evidence is insufficient. -- Clarifying questions are not prioritized or fewer than 3 when needed. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategy-kernel-extraction-from-context/agents/openai.yaml b/skills/strategy-kernel-extraction-from-context/agents/openai.yaml deleted file mode 100644 index fb231ab9..00000000 --- a/skills/strategy-kernel-extraction-from-context/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Strategy Kernel extraction from context" - short_description: "Strategy Kernel extraction from context. Use when the user needs a product workflow for product strategy related to..." - brand_color: "#059669" - default_prompt: "Use $strategy-kernel-extraction-from-context with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/strategy-kernel-extraction-from-context/productize.json b/skills/strategy-kernel-extraction-from-context/productize.json deleted file mode 100644 index 318d5f51..00000000 --- a/skills/strategy-kernel-extraction-from-context/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Strategy Kernel extraction from context", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "strategy-kernel-extraction-from-context", - "kernel", - "extraction", - "context", - "use" - ], - "use_when": "Strategy Kernel extraction from context. Use when the user needs a product workflow for product strategy related to strategy kernel extraction from context. Trigger terms: strategy, product-management, diagnosis, context.", - "do_not_use_when": "Do not use Strategy Kernel extraction from context when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Strategy Kernel extraction from context strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "strategy-kernel-extraction-from-context", - "kernel", - "extraction", - "context", - "use" - ], - "framework_fit": "Strategy Kernel extraction from context fits Strategy work in the Strategize lifecycle when the user needs Strategy Kernel extraction from context strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Strategy Kernel extraction from context strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Strategy Kernel extraction from context as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Strategy Kernel extraction from context when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $strategy-kernel-extraction-from-context to turn this kernel context into a decision-ready Strategy Kernel extraction from context strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Strategy Kernel extraction from context strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/strategy-to-execution-bridge-for-ux-decisions/SKILL.md b/skills/strategy-to-execution-bridge-for-ux-decisions/SKILL.md deleted file mode 100644 index 50d79cee..00000000 --- a/skills/strategy-to-execution-bridge-for-ux-decisions/SKILL.md +++ /dev/null @@ -1,817 +0,0 @@ ---- -name: strategy-to-execution-bridge-for-ux-decisions -description: >- - Strategy-to-execution bridge for UX decisions. Use when the user needs a product workflow - for product strategy related to strategy-to-execution bridge for ux decisions. Trigger - terms: ux, product-strategy, execution, roadmapping. ---- - - - -# Strategy-to-execution bridge for UX decisions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `strategy-to-execution-bridge-for-ux-decisions` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Strategy-to-execution bridge for UX decisions strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Strategy-to-execution bridge for UX decisions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{VISION_STRATEGY}} -- {{CURRENT_QUARTER_OBJECTIVES}} -- {{DESIGN_TEAM_CAPACITY}} -- {{EXISTING_DESIGN_SYSTEM}} -- {{TECHNICAL_CONSTRAINTS}} - - -GOAL -Produce a high-quality deliverable for: "Strategy-to-execution bridge for UX decisions". -Success metric: -- Translates vision and objectives into concrete UX principles, patterns, and execution plans. -- Produces a quarter-by-quarter roadmap with dependencies, risks, and success criteria. -- Provides decision frameworks that connect daily design choices to strategy. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if information is missing, state assumptions explicitly. -- Extract 3โ€“5 strategic themes and map them to UX goals, patterns, and decision principles. -- Build a quarterly execution plan with dependencies, success criteria, and capacity fit. -- Identify gaps, blockers, and research needs that prevent execution. -- Provide a multi-phase roadmap, validation plan, and feedback loops. - -FORMAT -Return exactly this structure: - - - -## Strategic Themes - -[List 3โ€“5 core strategic themes extracted from vision, with brief explanation of each] - -**Theme 1: [Name]** -- Description: [What this theme means strategically] -- UX implications: [How this affects user experience] -- Key phrases from vision: "[Quote relevant language]" - -**Theme 2: [Name]** -[Same structure] - -## User Experience Goals - -[Specific UX outcomes mentioned or strongly implied by vision] - -1. **[Goal name]:** [Description and rationale] - - Success looks like: [Observable outcome] - - Measurement: [How to track progress] - -2. **[Goal name]:** [Description] - [Continue for each goal] - -## Market Positioning - -**Target positioning:** [Premium/accessible, technical/intuitive, comprehensive/focused, etc.] -**Competitive differentiation:** [How vision positions against competitors] -**Customer segment priority:** [Which personas or segments are prioritized] -**Brand personality:** [Tone, voice, aesthetic implied] - -## Vision Gaps and Ambiguities - -[Areas where vision is too vague for execution] - -- **Ambiguity:** "[Vague term or conflicting signal]" - - **Why this matters:** [Impact on design decisions] - - **Question to resolve:** [Specific question stakeholders must answer] - - **Temporary assumption:** [What to assume if answer isn't available] - -[Continue for each ambiguity] - - - - -## Design Principles - -[4โ€“6 principles that operationalize the vision โ€“ avoid generic platitudes] - -**Principle 1: [Specific, actionable principle]** -- **What it means:** [Operational definition] -- **How to apply:** [Decision heuristic or guideline] -- **Example:** [Concrete example of principle in action] -- **Anti-pattern:** [What to avoid that violates this principle] - -**Principle 2: [Name]** -[Same structure] - -## Required UX Patterns - -[Specific interaction patterns needed to realize strategic themes] - -**Strategic Theme:** [Theme name] - -**Required Patterns:** -1. **[Pattern name]** โ€“ [Brief description] - - Use cases: [Where this pattern appears] - - Component needs: [Design system elements required] - - Examples: [Reference products or specific instances] - -2. **[Pattern name]** โ€“ [Description] - [Continue] - -[Repeat for each strategic theme] - -## Information Architecture Implications - -[How vision affects IA and content structure] - -**Navigation strategy:** [Top-level navigation approach implied by vision โ€“ task-based, feature-based, role-based, etc.] -**Content hierarchy:** [What information is primary vs. secondary] -**Discoverability approach:** [How users find features โ€“ guided onboarding, search-first, exploration, etc.] -**Conceptual model:** [How vision wants users to think about the product] - -**IA changes needed:** -- [Specific IA shifts required to align with vision] -- [Continue] - -## Visual and Interaction Design Direction - -**Aesthetic:** [Visual style implied โ€“ minimal, expressive, data-dense, spacious, etc.] -**Interaction patterns:** [Gestural, form-based, conversational, drag-and-drop, etc.] -**Motion and animation:** [Role of animation โ€“ functional only, delightful, prominent, minimal] -**Density and spacing:** [Information density โ€“ compact, generous, adaptive] -**Color strategy:** [Use of color โ€“ vibrant, muted, semantic only, brand-forward] - -## Component and Pattern Inventory - -[Comprehensive list of design system components needed for vision] - -**Existing components sufficient for vision:** -- [Component name] โ€“ [How it supports vision] -- [Continue] - -**Existing components needing enhancement:** -- [Component name] โ€“ [What enhancement is needed and why] -- [Continue] - -**New components required:** -- [Component name] โ€“ [Purpose and rationale] - - Priority: [Critical / High / Medium / Low] - - Dependencies: [What must exist first] - - Effort estimate: [Design days / complexity] -- [Continue] - - - - -## Q1 Scope: Actionable This Quarter - -[Vision elements that can be designed and delivered this quarter] - -### Initiative 1: [Name] - -**Strategic theme:** [Which theme this advances] -**Design deliverables:** -- [Specific deliverable] โ€“ [Completion date] -- [Continue] - -**Design effort:** [X days research, Y days design, Z iteration cycles] -**Dependencies:** -- Design: [Dependencies within design team] -- Research: [User research needs] -- Engineering: [Technical dependencies] -- Product: [Product decisions needed] -- External: [Third-party or other team dependencies] - -**Success criteria:** -- Design quality: [Standards to meet] -- User outcomes: [Behavioral or satisfaction metrics] -- Business metrics: [Adoption, conversion, revenue, etc.] -- Learning goals: [Assumptions validated or de-risked] - -**Risks and mitigations:** -- **Risk:** [Potential issue] - - **Likelihood:** [High/Medium/Low] - - **Impact:** [High/Medium/Low] - - **Mitigation:** [How to reduce risk] - -[Continue for each Q1 initiative] - -## Foundational Work Required - -[Prerequisite work needed before vision elements can be executed] - -### Foundation 1: [Name] - -**What it enables:** [Which vision elements depend on this] -**Why it's foundational:** [Explanation of dependency] -**Deliverables:** -- [Specific output] -- [Continue] - -**Timeline:** [When this must be complete and why] -**Effort:** [Resource estimate] - -[Continue for each foundational item] - -## Deferred to Q2+ - -[Vision elements not actionable this quarter] - -### Deferred Initiative: [Name] - -**Strategic theme:** [Which theme this advances] -**Why deferred:** [Blocker โ€“ capacity, dependencies, uncertainty, etc.] -**What's needed to activate:** -- [Prerequisite] โ€“ [Who/what/when] -- [Continue] - -**Tentative timeline:** [When this could begin] - -[Continue for each deferred item] - -## Capacity Analysis - -**Total design capacity:** [X designer-days available this quarter] -**Allocated capacity:** -- Q1 initiatives: [Y designer-days] ([Z]% of capacity) -- Foundational work: [Y designer-days] ([Z]%) -- Maintenance and support: [Y designer-days] ([Z]%) -- Buffer for unknowns: [Y designer-days] ([Z]%) - -**Capacity status:** [Over-committed / Fully allocated / Under-utilized] - -**Recommendations:** -- [If over-committed: what to descope or defer] -- [If under-utilized: what to pull forward or invest in] -- [Prioritization rationale] - - - - -## Daily Design Decision Criteria - -[Questions to ask when making design choices to ensure vision alignment] - -### When Choosing Between Design Alternatives - -1. **Vision alignment check:** Which option better advances strategic themes [list themes]? - - Option A: [How it aligns or conflicts] - - Option B: [How it aligns or conflicts] - - Winner: [Which to choose and why] - -2. **Scalability evaluation:** Which option extends to future use cases implied by vision? - - Consider: [Upcoming features or use cases] - - Test: [Can this pattern handle those scenarios?] - -3. **Consistency assessment:** Which option reinforces established patterns vs. introducing divergence? - - If new pattern is needed: [Justify with strategic rationale] - - If consistency conflicts with vision: [Escalate or document tradeoff] - -4. **User value prioritization:** Which option prioritizes user needs over internal convenience? - - Red flag: [Designs optimized for engineering simplicity or business politics over UX] - -5. **Technical feasibility reality check:** Is this implementable within constraints? - - If not: [Adjust design or advocate for constraint removal] - - If workaround needed: [Ensure workaround doesn't degrade UX] - -### When Vision and Immediate Needs Conflict - -**Favor vision if:** -- Immediate need is temporary or can be solved another way -- Vision direction is high-confidence and well-validated -- Technical debt from immediate solution is significant - -**Favor immediate need if:** -- Blocker for users or business (not just internal inconvenience) -- Vision direction is uncertain or likely to change -- Can be implemented without major technical debt - -**Seek creative middle ground:** -- Phased rollout (simple now, vision-aligned later) -- Feature flags (ship both, test and learn) -- Modular design (immediate solution doesn't preclude vision path) - -**Escalate when:** -- Tradeoff has significant strategic implications -- Decision affects multiple teams or long-term architecture -- Stakeholder alignment is needed - -### Pattern Establishment vs. Deferral - -**Standardize now if:** -- Pattern will be used in 3+ places imminently -- Consistency is critical for usability (e.g., error handling, form validation) -- Foundation for other patterns (e.g., base components) - -**Defer standardization if:** -- Single-use or rare use case -- Vision direction unclear and pattern may change -- Pattern is experimental and needs validation first - -**Create flexible pattern if:** -- Vision direction uncertain but action needed now -- Multiple future variations likely -- Learning required before locking in specific implementation - -### Scope Management - -**When new requests arise outside quarterly plan:** - -1. **Does this directly advance a Q1 vision element?** - - Yes โ†’ Evaluate against current priorities - - No โ†’ Default to defer unless exception criteria met - -2. **Exception criteria:** - - Critical user blocker (cannot accomplish core tasks) - - Regulatory or legal requirement - - Foundational for Q2+ work (pull forward) - - Opportunistic (very low effort, high strategic value) - -3. **If considering inclusion, ask: What would we deprioritize?** - - Evaluate tradeoff explicitly - - Ensure swapped item is truly lower priority - - Get stakeholder alignment on change - -4. **Can this be achieved with existing patterns?** - - Yes โ†’ Lower cost, more likely to include - - No โ†’ Higher bar for inclusion - - - - -## Strategic Gaps Requiring Clarification - -[Where strategy needs more definition before design can proceed confidently] - -**Gap 1: [Topic]** -- **Ambiguity:** [What's unclear] -- **Design impact:** [Why this blocks or confuses design work] -- **Question for stakeholders:** [Specific question] -- **Decision owner:** [Who should answer] -- **Urgency:** [When answer is needed โ€“ this week, this month, this quarter] -- **Temporary path forward:** [What to assume if answer delayed] - -[Continue for each strategic gap] - -## Technical Dependencies and Blockers - -[Required technical capabilities that don't exist yet] - -**Dependency 1: [Capability name]** -- **What it enables:** [Design work or vision elements blocked without this] -- **Current status:** [Not started / In progress / Blocked] -- **Owner:** [Team or person responsible] -- **Timeline:** [When this will be available] -- **Design impact if delayed:** [Consequences for design roadmap] -- **Workaround if unavailable:** [Alternative approach or descoped experience] - -[Continue for each technical dependency] - -## Research Needs and Unknowns - -[Questions that must be answered through user research] - -**Research Need 1: [Topic]** -- **Question:** [Specific research question] -- **Why this matters:** [Design decisions that depend on answer] -- **Hypotheses:** [Current assumptions to validate or invalidate] -- **Research method:** [Interviews, usability testing, survey, analytics analysis, etc.] -- **Participants:** [Who to include โ€“ personas, segments, sample size] -- **Timeline:** [When research must complete to inform design] -- **Owner:** [Researcher or designer responsible] -- **Design path if answer is X:** [Decision tree based on findings] -- **Design path if answer is Y:** [Alternative direction] - -[Continue for each research need] - -## Design System Gaps - -[Missing design system components or patterns needed for vision] - -**Gap 1: [Component or pattern name]** -- **Vision element requiring this:** [Strategic theme or initiative this supports] -- **Why existing components insufficient:** [What's missing or inadequate] -- **Scope of new component:** - - States: [Default, hover, focus, disabled, error, loading, etc.] - - Variants: [Size, style, or functional variations needed] - - Responsive behavior: [Mobile, tablet, desktop considerations] - - Accessibility requirements: [Keyboard nav, screen reader, WCAG compliance] -- **Effort estimate:** [Design days, complexity level] -- **Dependencies:** [Other components or patterns this builds on] -- **Priority:** [Critical / High / Medium / Low] -- **Timeline need:** [When this must be ready] - -[Continue for each design system gap] - -## Cross-Functional Dependencies - -[What other teams must deliver for design to proceed or ship] - -**Dependency on [Team Name]:** -- **What's needed:** [Specific deliverable or decision] -- **Why design needs this:** [Blocker explanation] -- **Owner:** [Name or role] -- **Requested by:** [Date] -- **Committed date:** [When they'll deliver, if known] -- **Status:** [On track / At risk / Blocked / Unknown] -- **Design contingency:** [What design does if this is delayed] - -[Continue for each cross-functional dependency] - - - - -## Phase 1: Current Quarter (Q1) โ€“ Foundation and Momentum - -**Timeline:** [Dates] -**Goal:** [High-level objective for this phase] - -### Foundational Work -[Work that enables future phases โ€“ design system, research, core patterns] - -**Foundation:** [Name] -- **Deliverables:** [Specific outputs] -- **Effort:** [Resource estimate] -- **Completion:** [Target date] -- **Unlocks:** [What becomes possible after this] - -[Continue for each foundation] - -### Quick Wins -[High-impact, low-effort improvements demonstrating vision progress] - -**Quick Win:** [Name] -- **Impact:** [User or business value] -- **Effort:** [Low effort explanation] -- **Delivery:** [Target date] -- **Strategic signal:** [Which vision theme this demonstrates] - -[Continue for each quick win] - -### Critical Path Items -[Blockers for Q2+ work that must complete this quarter] - -**Critical Item:** [Name] -- **Why critical:** [Explanation of dependency] -- **Risk if delayed:** [Downstream impact] -- **Deliverables:** [Specific outputs] -- **Date:** [Must complete by] - -[Continue for each critical item] - -### Learning Experiments -[Small tests to validate assumptions before major investment] - -**Experiment:** [Name] -- **Hypothesis:** [What we're testing] -- **Method:** [How we'll test โ€“ prototype, survey, A/B test, etc.] -- **Success criteria:** [What results validate hypothesis] -- **Failure criteria:** [What results invalidate hypothesis] -- **Decision:** [What we'll do based on results] -- **Timeline:** [Duration of experiment] - -[Continue for each experiment] - -### Q1 Success Criteria - -**Design outputs:** -- [ ] [Specific deliverable or milestone] -- [ ] [Continue] - -**User outcomes:** -- [ ] [Metric or qualitative signal] -- [ ] [Continue] - -**Business results:** -- [ ] [KPI or goal] -- [ ] [Continue] - -**Strategic progress:** -- [ ] [Vision element advanced or de-risked] -- [ ] [Continue] - -## Phase 2: Next Two Quarters (Q2โ€“Q3) โ€“ Building Toward Vision - -**Timeline:** [Dates] -**Goal:** [High-level objective for this phase] - -### Major Initiatives -[Large design efforts advancing core strategic themes] - -**Initiative:** [Name] -- **Strategic theme:** [Which theme this advances] -- **Scope:** [High-level description] -- **Dependencies:** [What from Phase 1 must be complete] -- **Milestones:** - - [Milestone 1] โ€“ [Date] - - [Milestone 2] โ€“ [Date] -- **Success criteria:** [How to measure success] - -[Continue for each major initiative] - -### Integration and Coherence Work -[Connecting Phase 1 foundations into cohesive experiences] - -**Integration Work:** [Name] -- **What's being integrated:** [Components, patterns, or features] -- **Why integration matters:** [User benefit or strategic value] -- **Timeline:** [When this happens] - -[Continue for each integration] - -### Iteration and Refinement -[Improving based on Phase 1 learnings] - -**Area for refinement:** [Name] -- **Phase 1 learning:** [What we learned] -- **Refinement needed:** [How to improve] -- **Timeline:** [When this happens] - -[Continue for each refinement area] - -### Decision Checkpoints -[Points where direction may adjust based on data] - -**Checkpoint:** [When โ€“ e.g., "End of Q2"] -- **Decision:** [What will be decided] -- **Data inputs:** [Metrics, research, or signals informing decision] -- **Options:** [Possible directions based on data] -- **Decision owner:** [Who decides] - -[Continue for each checkpoint] - -## Phase 3: Future Quarters (Q4+) โ€“ Vision Realization - -**Timeline:** [Dates or "Q4 and beyond"] -**Goal:** [High-level objective for this phase] - -### Vision Completion -[Fully realized strategic themes] - -**Strategic Theme:** [Name] -- **Vision state:** [Description of fully realized theme] -- **What's needed to complete:** - - [Work item] - - [Continue] -- **Success criteria:** [How to know theme is fully realized] - -[Continue for each strategic theme] - -### Polish and Elevation -[Raising experience quality to match vision] - -**Polish area:** [Name] -- **Current state:** [Where quality falls short] -- **Vision state:** [Target quality level] -- **Work required:** [What it takes to close gap] - -[Continue for each polish area] - -### Scale and Robustness -[Handling edge cases, localization, advanced use cases] - -**Scaling dimension:** [Name โ€“ e.g., "Localization," "Edge case handling"] -- **Scope:** [What must scale] -- **Complexity:** [Challenges involved] -- **Timeline:** [When this is addressed] - -[Continue for each scaling dimension] - -### Measurement and Validation -[Confirming strategic goals achieved] - -**Strategic goal:** [Goal from vision] -- **Measurement approach:** [How to validate achievement] -- **Target metric:** [Specific number or threshold] -- **Review cadence:** [When to check progress] - -[Continue for each strategic goal] - -## Ongoing Across All Phases - -### Maintenance and Debt Reduction -**Allocation:** [% of capacity per quarter] -**Focus areas:** -- [Area needing maintenance โ€“ e.g., "accessibility improvements," "mobile optimization"] -- [Continue] - -### Flexibility Buffer -**Allocation:** [% of capacity held for emerging priorities] -**Use for:** [Unplanned work, urgent requests, pivots] - -### Research and Discovery -**Allocation:** [% of capacity for ongoing learning] -**Focus:** [Continuous research to inform future phases] - -## Roadmap Visualization - -[If helpful, provide a timeline visual or table showing initiatives across phases] - -**Q1:** [List key initiatives] -**Q2:** [List key initiatives] -**Q3:** [List key initiatives] -**Q4+:** [List key initiatives] - - - - -## Vision Assumptions to Validate - -[Beliefs embedded in strategy that should be tested] - -**Assumption 1: [Statement]** -- **Type:** [Market / User behavior / Competitive / Business model] -- **Source:** [Where this assumption comes from in vision] -- **Confidence level:** [High / Medium / Low] -- **Validation method:** [How to test this] -- **Timeline:** [When to validate] -- **Impact if wrong:** [Consequence of false assumption] -- **Pivot options:** [Alternative directions if invalidated] - -[Continue for each assumption] - -## Design Hypotheses - -[Testable beliefs about UX approaches] - -**Hypothesis 1: [Statement]** -- **Rationale:** [Why we believe this] -- **Test method:** [How to validate โ€“ prototype testing, A/B test, analytics, etc.] -- **Success criteria:** [Evidence that confirms hypothesis] -- **Failure criteria:** [Evidence that refutes hypothesis] -- **Timeline:** [When to test] -- **Decision tree:** - - If validated: [Design direction to pursue] - - If invalidated: [Alternative approach] - - If inconclusive: [Further research or conservative path] - -[Continue for each hypothesis] - -## Success Indicators and Monitoring - -### Leading Indicators -[Early signals that validate or invalidate direction] - -**Indicator:** [Metric or signal] -- **What it measures:** [What this tells us] -- **Target:** [Threshold or trend] -- **Measurement method:** [How to track] -- **Frequency:** [How often to check] -- **Green flag:** [Signal we're on track] -- **Yellow flag:** [Signal to investigate] -- **Red flag:** [Signal to pivot] - -[Continue for each indicator] - -### Lagging Indicators -[Longer-term outcomes confirming strategic success] - -**Indicator:** [Metric or signal] -- **What it measures:** [What this tells us] -- **Target:** [Threshold or goal] -- **Timeline:** [When to expect result] -- **Measurement method:** [How to track] - -[Continue for each indicator] - -## Review Cadence and Feedback Loops - -### Weekly Design Reviews -**Attendees:** [Roles] -**Agenda:** -- Work in progress review -- **Strategy alignment check:** [Quick assessment of whether work advances vision] -- Blockers and dependencies -- Upcoming decisions - -### Mid-Quarter Checkpoint -**Timing:** [Week 6 of 13-week quarter] -**Purpose:** Assess if on track to hit Q1 success criteria -**Review:** -- Progress vs. plan -- Capacity actuals vs. estimates -- Dependency status -- Emerging risks -- Adjustment needs - -### End-of-Quarter Retrospective -**Timing:** [Final week of quarter] -**Purpose:** Learn and inform next quarter planning -**Review:** -- Q1 success criteria achievement -- Assumption validation results -- What worked well / What didn't -- Roadmap adjustments needed -- Phase 2 planning input - -### Strategy Review with Leadership -**Cadence:** [Quarterly or semi-annually] -**Purpose:** Ensure design work aligns with evolving business strategy -**Topics:** -- Vision progress report -- Key learnings and pivots -- Roadmap alignment with business priorities -- Resource needs for upcoming phases - -## Escalation Triggers - -[When to pause and reconsider direction] - -**Trigger 1: User research contradicts core assumptions** -- **Action:** [Immediate review of affected design work, stakeholder alignment meeting] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 2: Technical feasibility proves impossible or dramatically more expensive** -- **Action:** [Evaluate alternative approaches, possibly descope or rearchitect] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 3: Business priorities shift** -- **Action:** [Reassess roadmap, reprioritize quarterly plan] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 4: Competitive landscape changes significantly** -- **Action:** [Competitive analysis update, strategy review meeting] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 5: Success metrics trending negatively** -- **Action:** [Root cause analysis, corrective action plan] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Strategic themes or UX goals are missing or not tied to the vision. -- Execution plan lacks dependencies, success criteria, or capacity analysis. -- Validation and feedback loops are missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategy-to-execution-bridge-for-ux-decisions/SKILL.md.tmpl b/skills/strategy-to-execution-bridge-for-ux-decisions/SKILL.md.tmpl deleted file mode 100644 index 6b9f99cc..00000000 --- a/skills/strategy-to-execution-bridge-for-ux-decisions/SKILL.md.tmpl +++ /dev/null @@ -1,758 +0,0 @@ ---- -name: strategy-to-execution-bridge-for-ux-decisions -description: >- - Strategy-to-execution bridge for UX decisions. Use when the user needs a product workflow - for product strategy related to strategy-to-execution bridge for ux decisions. Trigger - terms: ux, product-strategy, execution, roadmapping. ---- -# Strategy-to-execution bridge for UX decisions - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Strategy-to-execution bridge for UX decisions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{VISION_STRATEGY}} -- {{CURRENT_QUARTER_OBJECTIVES}} -- {{DESIGN_TEAM_CAPACITY}} -- {{EXISTING_DESIGN_SYSTEM}} -- {{TECHNICAL_CONSTRAINTS}} - - -GOAL -Produce a high-quality deliverable for: "Strategy-to-execution bridge for UX decisions". -Success metric: -- Translates vision and objectives into concrete UX principles, patterns, and execution plans. -- Produces a quarter-by-quarter roadmap with dependencies, risks, and success criteria. -- Provides decision frameworks that connect daily design choices to strategy. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if information is missing, state assumptions explicitly. -- Extract 3โ€“5 strategic themes and map them to UX goals, patterns, and decision principles. -- Build a quarterly execution plan with dependencies, success criteria, and capacity fit. -- Identify gaps, blockers, and research needs that prevent execution. -- Provide a multi-phase roadmap, validation plan, and feedback loops. - -FORMAT -Return exactly this structure: - - - -## Strategic Themes - -[List 3โ€“5 core strategic themes extracted from vision, with brief explanation of each] - -**Theme 1: [Name]** -- Description: [What this theme means strategically] -- UX implications: [How this affects user experience] -- Key phrases from vision: "[Quote relevant language]" - -**Theme 2: [Name]** -[Same structure] - -## User Experience Goals - -[Specific UX outcomes mentioned or strongly implied by vision] - -1. **[Goal name]:** [Description and rationale] - - Success looks like: [Observable outcome] - - Measurement: [How to track progress] - -2. **[Goal name]:** [Description] - [Continue for each goal] - -## Market Positioning - -**Target positioning:** [Premium/accessible, technical/intuitive, comprehensive/focused, etc.] -**Competitive differentiation:** [How vision positions against competitors] -**Customer segment priority:** [Which personas or segments are prioritized] -**Brand personality:** [Tone, voice, aesthetic implied] - -## Vision Gaps and Ambiguities - -[Areas where vision is too vague for execution] - -- **Ambiguity:** "[Vague term or conflicting signal]" - - **Why this matters:** [Impact on design decisions] - - **Question to resolve:** [Specific question stakeholders must answer] - - **Temporary assumption:** [What to assume if answer isn't available] - -[Continue for each ambiguity] - - - - -## Design Principles - -[4โ€“6 principles that operationalize the vision โ€“ avoid generic platitudes] - -**Principle 1: [Specific, actionable principle]** -- **What it means:** [Operational definition] -- **How to apply:** [Decision heuristic or guideline] -- **Example:** [Concrete example of principle in action] -- **Anti-pattern:** [What to avoid that violates this principle] - -**Principle 2: [Name]** -[Same structure] - -## Required UX Patterns - -[Specific interaction patterns needed to realize strategic themes] - -**Strategic Theme:** [Theme name] - -**Required Patterns:** -1. **[Pattern name]** โ€“ [Brief description] - - Use cases: [Where this pattern appears] - - Component needs: [Design system elements required] - - Examples: [Reference products or specific instances] - -2. **[Pattern name]** โ€“ [Description] - [Continue] - -[Repeat for each strategic theme] - -## Information Architecture Implications - -[How vision affects IA and content structure] - -**Navigation strategy:** [Top-level navigation approach implied by vision โ€“ task-based, feature-based, role-based, etc.] -**Content hierarchy:** [What information is primary vs. secondary] -**Discoverability approach:** [How users find features โ€“ guided onboarding, search-first, exploration, etc.] -**Conceptual model:** [How vision wants users to think about the product] - -**IA changes needed:** -- [Specific IA shifts required to align with vision] -- [Continue] - -## Visual and Interaction Design Direction - -**Aesthetic:** [Visual style implied โ€“ minimal, expressive, data-dense, spacious, etc.] -**Interaction patterns:** [Gestural, form-based, conversational, drag-and-drop, etc.] -**Motion and animation:** [Role of animation โ€“ functional only, delightful, prominent, minimal] -**Density and spacing:** [Information density โ€“ compact, generous, adaptive] -**Color strategy:** [Use of color โ€“ vibrant, muted, semantic only, brand-forward] - -## Component and Pattern Inventory - -[Comprehensive list of design system components needed for vision] - -**Existing components sufficient for vision:** -- [Component name] โ€“ [How it supports vision] -- [Continue] - -**Existing components needing enhancement:** -- [Component name] โ€“ [What enhancement is needed and why] -- [Continue] - -**New components required:** -- [Component name] โ€“ [Purpose and rationale] - - Priority: [Critical / High / Medium / Low] - - Dependencies: [What must exist first] - - Effort estimate: [Design days / complexity] -- [Continue] - - - - -## Q1 Scope: Actionable This Quarter - -[Vision elements that can be designed and delivered this quarter] - -### Initiative 1: [Name] - -**Strategic theme:** [Which theme this advances] -**Design deliverables:** -- [Specific deliverable] โ€“ [Completion date] -- [Continue] - -**Design effort:** [X days research, Y days design, Z iteration cycles] -**Dependencies:** -- Design: [Dependencies within design team] -- Research: [User research needs] -- Engineering: [Technical dependencies] -- Product: [Product decisions needed] -- External: [Third-party or other team dependencies] - -**Success criteria:** -- Design quality: [Standards to meet] -- User outcomes: [Behavioral or satisfaction metrics] -- Business metrics: [Adoption, conversion, revenue, etc.] -- Learning goals: [Assumptions validated or de-risked] - -**Risks and mitigations:** -- **Risk:** [Potential issue] - - **Likelihood:** [High/Medium/Low] - - **Impact:** [High/Medium/Low] - - **Mitigation:** [How to reduce risk] - -[Continue for each Q1 initiative] - -## Foundational Work Required - -[Prerequisite work needed before vision elements can be executed] - -### Foundation 1: [Name] - -**What it enables:** [Which vision elements depend on this] -**Why it's foundational:** [Explanation of dependency] -**Deliverables:** -- [Specific output] -- [Continue] - -**Timeline:** [When this must be complete and why] -**Effort:** [Resource estimate] - -[Continue for each foundational item] - -## Deferred to Q2+ - -[Vision elements not actionable this quarter] - -### Deferred Initiative: [Name] - -**Strategic theme:** [Which theme this advances] -**Why deferred:** [Blocker โ€“ capacity, dependencies, uncertainty, etc.] -**What's needed to activate:** -- [Prerequisite] โ€“ [Who/what/when] -- [Continue] - -**Tentative timeline:** [When this could begin] - -[Continue for each deferred item] - -## Capacity Analysis - -**Total design capacity:** [X designer-days available this quarter] -**Allocated capacity:** -- Q1 initiatives: [Y designer-days] ([Z]% of capacity) -- Foundational work: [Y designer-days] ([Z]%) -- Maintenance and support: [Y designer-days] ([Z]%) -- Buffer for unknowns: [Y designer-days] ([Z]%) - -**Capacity status:** [Over-committed / Fully allocated / Under-utilized] - -**Recommendations:** -- [If over-committed: what to descope or defer] -- [If under-utilized: what to pull forward or invest in] -- [Prioritization rationale] - - - - -## Daily Design Decision Criteria - -[Questions to ask when making design choices to ensure vision alignment] - -### When Choosing Between Design Alternatives - -1. **Vision alignment check:** Which option better advances strategic themes [list themes]? - - Option A: [How it aligns or conflicts] - - Option B: [How it aligns or conflicts] - - Winner: [Which to choose and why] - -2. **Scalability evaluation:** Which option extends to future use cases implied by vision? - - Consider: [Upcoming features or use cases] - - Test: [Can this pattern handle those scenarios?] - -3. **Consistency assessment:** Which option reinforces established patterns vs. introducing divergence? - - If new pattern is needed: [Justify with strategic rationale] - - If consistency conflicts with vision: [Escalate or document tradeoff] - -4. **User value prioritization:** Which option prioritizes user needs over internal convenience? - - Red flag: [Designs optimized for engineering simplicity or business politics over UX] - -5. **Technical feasibility reality check:** Is this implementable within constraints? - - If not: [Adjust design or advocate for constraint removal] - - If workaround needed: [Ensure workaround doesn't degrade UX] - -### When Vision and Immediate Needs Conflict - -**Favor vision if:** -- Immediate need is temporary or can be solved another way -- Vision direction is high-confidence and well-validated -- Technical debt from immediate solution is significant - -**Favor immediate need if:** -- Blocker for users or business (not just internal inconvenience) -- Vision direction is uncertain or likely to change -- Can be implemented without major technical debt - -**Seek creative middle ground:** -- Phased rollout (simple now, vision-aligned later) -- Feature flags (ship both, test and learn) -- Modular design (immediate solution doesn't preclude vision path) - -**Escalate when:** -- Tradeoff has significant strategic implications -- Decision affects multiple teams or long-term architecture -- Stakeholder alignment is needed - -### Pattern Establishment vs. Deferral - -**Standardize now if:** -- Pattern will be used in 3+ places imminently -- Consistency is critical for usability (e.g., error handling, form validation) -- Foundation for other patterns (e.g., base components) - -**Defer standardization if:** -- Single-use or rare use case -- Vision direction unclear and pattern may change -- Pattern is experimental and needs validation first - -**Create flexible pattern if:** -- Vision direction uncertain but action needed now -- Multiple future variations likely -- Learning required before locking in specific implementation - -### Scope Management - -**When new requests arise outside quarterly plan:** - -1. **Does this directly advance a Q1 vision element?** - - Yes โ†’ Evaluate against current priorities - - No โ†’ Default to defer unless exception criteria met - -2. **Exception criteria:** - - Critical user blocker (cannot accomplish core tasks) - - Regulatory or legal requirement - - Foundational for Q2+ work (pull forward) - - Opportunistic (very low effort, high strategic value) - -3. **If considering inclusion, ask: What would we deprioritize?** - - Evaluate tradeoff explicitly - - Ensure swapped item is truly lower priority - - Get stakeholder alignment on change - -4. **Can this be achieved with existing patterns?** - - Yes โ†’ Lower cost, more likely to include - - No โ†’ Higher bar for inclusion - - - - -## Strategic Gaps Requiring Clarification - -[Where strategy needs more definition before design can proceed confidently] - -**Gap 1: [Topic]** -- **Ambiguity:** [What's unclear] -- **Design impact:** [Why this blocks or confuses design work] -- **Question for stakeholders:** [Specific question] -- **Decision owner:** [Who should answer] -- **Urgency:** [When answer is needed โ€“ this week, this month, this quarter] -- **Temporary path forward:** [What to assume if answer delayed] - -[Continue for each strategic gap] - -## Technical Dependencies and Blockers - -[Required technical capabilities that don't exist yet] - -**Dependency 1: [Capability name]** -- **What it enables:** [Design work or vision elements blocked without this] -- **Current status:** [Not started / In progress / Blocked] -- **Owner:** [Team or person responsible] -- **Timeline:** [When this will be available] -- **Design impact if delayed:** [Consequences for design roadmap] -- **Workaround if unavailable:** [Alternative approach or descoped experience] - -[Continue for each technical dependency] - -## Research Needs and Unknowns - -[Questions that must be answered through user research] - -**Research Need 1: [Topic]** -- **Question:** [Specific research question] -- **Why this matters:** [Design decisions that depend on answer] -- **Hypotheses:** [Current assumptions to validate or invalidate] -- **Research method:** [Interviews, usability testing, survey, analytics analysis, etc.] -- **Participants:** [Who to include โ€“ personas, segments, sample size] -- **Timeline:** [When research must complete to inform design] -- **Owner:** [Researcher or designer responsible] -- **Design path if answer is X:** [Decision tree based on findings] -- **Design path if answer is Y:** [Alternative direction] - -[Continue for each research need] - -## Design System Gaps - -[Missing design system components or patterns needed for vision] - -**Gap 1: [Component or pattern name]** -- **Vision element requiring this:** [Strategic theme or initiative this supports] -- **Why existing components insufficient:** [What's missing or inadequate] -- **Scope of new component:** - - States: [Default, hover, focus, disabled, error, loading, etc.] - - Variants: [Size, style, or functional variations needed] - - Responsive behavior: [Mobile, tablet, desktop considerations] - - Accessibility requirements: [Keyboard nav, screen reader, WCAG compliance] -- **Effort estimate:** [Design days, complexity level] -- **Dependencies:** [Other components or patterns this builds on] -- **Priority:** [Critical / High / Medium / Low] -- **Timeline need:** [When this must be ready] - -[Continue for each design system gap] - -## Cross-Functional Dependencies - -[What other teams must deliver for design to proceed or ship] - -**Dependency on [Team Name]:** -- **What's needed:** [Specific deliverable or decision] -- **Why design needs this:** [Blocker explanation] -- **Owner:** [Name or role] -- **Requested by:** [Date] -- **Committed date:** [When they'll deliver, if known] -- **Status:** [On track / At risk / Blocked / Unknown] -- **Design contingency:** [What design does if this is delayed] - -[Continue for each cross-functional dependency] - - - - -## Phase 1: Current Quarter (Q1) โ€“ Foundation and Momentum - -**Timeline:** [Dates] -**Goal:** [High-level objective for this phase] - -### Foundational Work -[Work that enables future phases โ€“ design system, research, core patterns] - -**Foundation:** [Name] -- **Deliverables:** [Specific outputs] -- **Effort:** [Resource estimate] -- **Completion:** [Target date] -- **Unlocks:** [What becomes possible after this] - -[Continue for each foundation] - -### Quick Wins -[High-impact, low-effort improvements demonstrating vision progress] - -**Quick Win:** [Name] -- **Impact:** [User or business value] -- **Effort:** [Low effort explanation] -- **Delivery:** [Target date] -- **Strategic signal:** [Which vision theme this demonstrates] - -[Continue for each quick win] - -### Critical Path Items -[Blockers for Q2+ work that must complete this quarter] - -**Critical Item:** [Name] -- **Why critical:** [Explanation of dependency] -- **Risk if delayed:** [Downstream impact] -- **Deliverables:** [Specific outputs] -- **Date:** [Must complete by] - -[Continue for each critical item] - -### Learning Experiments -[Small tests to validate assumptions before major investment] - -**Experiment:** [Name] -- **Hypothesis:** [What we're testing] -- **Method:** [How we'll test โ€“ prototype, survey, A/B test, etc.] -- **Success criteria:** [What results validate hypothesis] -- **Failure criteria:** [What results invalidate hypothesis] -- **Decision:** [What we'll do based on results] -- **Timeline:** [Duration of experiment] - -[Continue for each experiment] - -### Q1 Success Criteria - -**Design outputs:** -- [ ] [Specific deliverable or milestone] -- [ ] [Continue] - -**User outcomes:** -- [ ] [Metric or qualitative signal] -- [ ] [Continue] - -**Business results:** -- [ ] [KPI or goal] -- [ ] [Continue] - -**Strategic progress:** -- [ ] [Vision element advanced or de-risked] -- [ ] [Continue] - -## Phase 2: Next Two Quarters (Q2โ€“Q3) โ€“ Building Toward Vision - -**Timeline:** [Dates] -**Goal:** [High-level objective for this phase] - -### Major Initiatives -[Large design efforts advancing core strategic themes] - -**Initiative:** [Name] -- **Strategic theme:** [Which theme this advances] -- **Scope:** [High-level description] -- **Dependencies:** [What from Phase 1 must be complete] -- **Milestones:** - - [Milestone 1] โ€“ [Date] - - [Milestone 2] โ€“ [Date] -- **Success criteria:** [How to measure success] - -[Continue for each major initiative] - -### Integration and Coherence Work -[Connecting Phase 1 foundations into cohesive experiences] - -**Integration Work:** [Name] -- **What's being integrated:** [Components, patterns, or features] -- **Why integration matters:** [User benefit or strategic value] -- **Timeline:** [When this happens] - -[Continue for each integration] - -### Iteration and Refinement -[Improving based on Phase 1 learnings] - -**Area for refinement:** [Name] -- **Phase 1 learning:** [What we learned] -- **Refinement needed:** [How to improve] -- **Timeline:** [When this happens] - -[Continue for each refinement area] - -### Decision Checkpoints -[Points where direction may adjust based on data] - -**Checkpoint:** [When โ€“ e.g., "End of Q2"] -- **Decision:** [What will be decided] -- **Data inputs:** [Metrics, research, or signals informing decision] -- **Options:** [Possible directions based on data] -- **Decision owner:** [Who decides] - -[Continue for each checkpoint] - -## Phase 3: Future Quarters (Q4+) โ€“ Vision Realization - -**Timeline:** [Dates or "Q4 and beyond"] -**Goal:** [High-level objective for this phase] - -### Vision Completion -[Fully realized strategic themes] - -**Strategic Theme:** [Name] -- **Vision state:** [Description of fully realized theme] -- **What's needed to complete:** - - [Work item] - - [Continue] -- **Success criteria:** [How to know theme is fully realized] - -[Continue for each strategic theme] - -### Polish and Elevation -[Raising experience quality to match vision] - -**Polish area:** [Name] -- **Current state:** [Where quality falls short] -- **Vision state:** [Target quality level] -- **Work required:** [What it takes to close gap] - -[Continue for each polish area] - -### Scale and Robustness -[Handling edge cases, localization, advanced use cases] - -**Scaling dimension:** [Name โ€“ e.g., "Localization," "Edge case handling"] -- **Scope:** [What must scale] -- **Complexity:** [Challenges involved] -- **Timeline:** [When this is addressed] - -[Continue for each scaling dimension] - -### Measurement and Validation -[Confirming strategic goals achieved] - -**Strategic goal:** [Goal from vision] -- **Measurement approach:** [How to validate achievement] -- **Target metric:** [Specific number or threshold] -- **Review cadence:** [When to check progress] - -[Continue for each strategic goal] - -## Ongoing Across All Phases - -### Maintenance and Debt Reduction -**Allocation:** [% of capacity per quarter] -**Focus areas:** -- [Area needing maintenance โ€“ e.g., "accessibility improvements," "mobile optimization"] -- [Continue] - -### Flexibility Buffer -**Allocation:** [% of capacity held for emerging priorities] -**Use for:** [Unplanned work, urgent requests, pivots] - -### Research and Discovery -**Allocation:** [% of capacity for ongoing learning] -**Focus:** [Continuous research to inform future phases] - -## Roadmap Visualization - -[If helpful, provide a timeline visual or table showing initiatives across phases] - -**Q1:** [List key initiatives] -**Q2:** [List key initiatives] -**Q3:** [List key initiatives] -**Q4+:** [List key initiatives] - - - - -## Vision Assumptions to Validate - -[Beliefs embedded in strategy that should be tested] - -**Assumption 1: [Statement]** -- **Type:** [Market / User behavior / Competitive / Business model] -- **Source:** [Where this assumption comes from in vision] -- **Confidence level:** [High / Medium / Low] -- **Validation method:** [How to test this] -- **Timeline:** [When to validate] -- **Impact if wrong:** [Consequence of false assumption] -- **Pivot options:** [Alternative directions if invalidated] - -[Continue for each assumption] - -## Design Hypotheses - -[Testable beliefs about UX approaches] - -**Hypothesis 1: [Statement]** -- **Rationale:** [Why we believe this] -- **Test method:** [How to validate โ€“ prototype testing, A/B test, analytics, etc.] -- **Success criteria:** [Evidence that confirms hypothesis] -- **Failure criteria:** [Evidence that refutes hypothesis] -- **Timeline:** [When to test] -- **Decision tree:** - - If validated: [Design direction to pursue] - - If invalidated: [Alternative approach] - - If inconclusive: [Further research or conservative path] - -[Continue for each hypothesis] - -## Success Indicators and Monitoring - -### Leading Indicators -[Early signals that validate or invalidate direction] - -**Indicator:** [Metric or signal] -- **What it measures:** [What this tells us] -- **Target:** [Threshold or trend] -- **Measurement method:** [How to track] -- **Frequency:** [How often to check] -- **Green flag:** [Signal we're on track] -- **Yellow flag:** [Signal to investigate] -- **Red flag:** [Signal to pivot] - -[Continue for each indicator] - -### Lagging Indicators -[Longer-term outcomes confirming strategic success] - -**Indicator:** [Metric or signal] -- **What it measures:** [What this tells us] -- **Target:** [Threshold or goal] -- **Timeline:** [When to expect result] -- **Measurement method:** [How to track] - -[Continue for each indicator] - -## Review Cadence and Feedback Loops - -### Weekly Design Reviews -**Attendees:** [Roles] -**Agenda:** -- Work in progress review -- **Strategy alignment check:** [Quick assessment of whether work advances vision] -- Blockers and dependencies -- Upcoming decisions - -### Mid-Quarter Checkpoint -**Timing:** [Week 6 of 13-week quarter] -**Purpose:** Assess if on track to hit Q1 success criteria -**Review:** -- Progress vs. plan -- Capacity actuals vs. estimates -- Dependency status -- Emerging risks -- Adjustment needs - -### End-of-Quarter Retrospective -**Timing:** [Final week of quarter] -**Purpose:** Learn and inform next quarter planning -**Review:** -- Q1 success criteria achievement -- Assumption validation results -- What worked well / What didn't -- Roadmap adjustments needed -- Phase 2 planning input - -### Strategy Review with Leadership -**Cadence:** [Quarterly or semi-annually] -**Purpose:** Ensure design work aligns with evolving business strategy -**Topics:** -- Vision progress report -- Key learnings and pivots -- Roadmap alignment with business priorities -- Resource needs for upcoming phases - -## Escalation Triggers - -[When to pause and reconsider direction] - -**Trigger 1: User research contradicts core assumptions** -- **Action:** [Immediate review of affected design work, stakeholder alignment meeting] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 2: Technical feasibility proves impossible or dramatically more expensive** -- **Action:** [Evaluate alternative approaches, possibly descope or rearchitect] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 3: Business priorities shift** -- **Action:** [Reassess roadmap, reprioritize quarterly plan] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 4: Competitive landscape changes significantly** -- **Action:** [Competitive analysis update, strategy review meeting] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - -**Trigger 5: Success metrics trending negatively** -- **Action:** [Root cause analysis, corrective action plan] -- **Decision owner:** [Role] -- **Timeline:** [How quickly to respond] - - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Strategic themes or UX goals are missing or not tied to the vision. -- Execution plan lacks dependencies, success criteria, or capacity analysis. -- Validation and feedback loops are missing or superficial. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/strategy-to-execution-bridge-for-ux-decisions/agents/openai.yaml b/skills/strategy-to-execution-bridge-for-ux-decisions/agents/openai.yaml deleted file mode 100644 index 7fa4b181..00000000 --- a/skills/strategy-to-execution-bridge-for-ux-decisions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Strategy-to-execution bridge for UX decisions" - short_description: "Strategy-to-execution bridge for UX decisions. Use when the user needs a product workflow for product strategy..." - brand_color: "#059669" - default_prompt: "Use $strategy-to-execution-bridge-for-ux-decisions with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/strategy-to-execution-bridge-for-ux-decisions/productize.json b/skills/strategy-to-execution-bridge-for-ux-decisions/productize.json deleted file mode 100644 index 82aed9e2..00000000 --- a/skills/strategy-to-execution-bridge-for-ux-decisions/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Strategy-to-execution bridge for UX decisions", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "strategy-to-execution-bridge-for-ux-decisions", - "execution", - "bridge", - "decisions", - "use" - ], - "use_when": "Strategy-to-execution bridge for UX decisions. Use when the user needs a product workflow for product strategy related to strategy-to-execution bridge for ux decisions. Trigger terms: ux, product-strategy, execution, roadmapping.", - "do_not_use_when": "Do not use Strategy-to-execution bridge for UX decisions when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Strategy-to-execution bridge for UX decisions strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "strategy-to-execution-bridge-for-ux-decisions", - "execution", - "bridge", - "decisions", - "use" - ], - "framework_fit": "Strategy-to-execution bridge for UX decisions fits Strategy work in the Strategize lifecycle when the user needs Strategy-to-execution bridge for UX decisions strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Strategy-to-execution bridge for UX decisions strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Strategy-to-execution bridge for UX decisions as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Strategy-to-execution bridge for UX decisions when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $strategy-to-execution-bridge-for-ux-decisions to turn this execution context into a decision-ready Strategy-to-execution bridge for UX decisions strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Strategy-to-execution bridge for UX decisions strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/structured-decision-journals-from-decisions-and-context/SKILL.md b/skills/structured-decision-journals-from-decisions-and-context/SKILL.md deleted file mode 100644 index 7f878430..00000000 --- a/skills/structured-decision-journals-from-decisions-and-context/SKILL.md +++ /dev/null @@ -1,200 +0,0 @@ ---- -name: structured-decision-journals-from-decisions-and-context -description: >- - Structured decision journals from decisions and context. Use when the user needs a product - workflow for decision making related to structured decision journals from decisions and - context. Trigger terms: pm, decision-making, journaling, forecasting, base-rates. ---- - - - -# Structured decision journals from decisions and context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-decision-journals-from-decisions-and-context` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Decision journal with decision frame, alternatives, outcomes, probabilities, base rates, disconfirming evidence, bias checklist, quit conditions, and review plan - -Use this skill to run the Productize prompt contract for **Structured decision journals from decisions and context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DECISION}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: "Structured decision journals from decisions and context". -Success metric: -- Produces a complete decision journal with all required sections filled from provided context. -- Probability estimates are coherent and sum to 100%. -- Quit conditions are measurable and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DECISION}}` and `{{CONTEXT}}`; if information is missing, state assumptions explicitly. -- Separate facts, assumptions, missing evidence, and risky leaps before forecasting. -- Generate 3-5 expected outcomes spanning best-case to worst-case and covering short-term and long-term effects. -- Provide one probability for each expected outcome; probabilities must total exactly 100%. -- Include the strongest alternative option considered, not only the chosen path. -- Provide 3-5 key assumptions that materially affect outcome validity. -- Provide relevant base rates/statistics tied to this decision type; if unavailable, provide directional proxies and label as assumptions. -- Include disconfirming evidence that would weaken the decision. -- Include a bias checklist for anchoring, availability, confirmation, sunk cost, status quo, optimism, and loss/risk aversion. -- Provide 2-3 measurable quit conditions with clear trigger thresholds. -- Provide a decision review date and owner. -- Keep `` intentionally blank for future updates. - -FORMAT -Return exactly this structure: - - - -[Decision, owner, date, context, and chosen option] - - - -Known facts: -Assumptions: -Missing evidence: -Risky leaps: - - - -1. [Chosen option] -2. [Strongest alternative] -3. [Optional additional alternative] - - - -1. [Outcome] -2. [Outcome] -3. [Outcome] -[Optional 4th and 5th outcome] - - - -1. [Outcome 1] - [X%] -2. [Outcome 2] - [Y%] -3. [Outcome 3] - [Z%] -[Optional 4th and 5th probability] -Total: 100% - - - -1. [Assumption] -2. [Assumption] -3. [Assumption] -[Optional 4th and 5th assumption] - - - -1. [Base rate/statistic + source context or rationale] -2. [Base rate/statistic + source context or rationale] -[Optional additional base rates] - - - -1. [Evidence that would weaken or reverse the decision] -2. [Evidence to seek before/after deciding] - - - -Anchoring: -Availability: -Confirmation: -Sunk cost / escalation: -Status quo: -Optimism: -Loss or risk aversion: - - - -1. [Condition + measurable threshold] -2. [Condition + measurable threshold] -[Optional 3rd condition] - - - - - - -Owner: -Review date: -What would change the decision: - - - -FAILURE -- Any required section in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 or more than 5 expected outcomes. -- Probability estimates do not map to outcomes or do not total 100%. -- Fewer than 3 key assumptions or fewer than 2 quit conditions. -- Quit conditions are not measurable. -- No strongest alternative, disconfirming evidence, bias checklist, review owner, or review date. -- Claims are generic or not grounded in provided inputs. -- `` is pre-filled with outcome claims. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-decision-journals-from-decisions-and-context/SKILL.md.tmpl b/skills/structured-decision-journals-from-decisions-and-context/SKILL.md.tmpl deleted file mode 100644 index ecec4025..00000000 --- a/skills/structured-decision-journals-from-decisions-and-context/SKILL.md.tmpl +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: structured-decision-journals-from-decisions-and-context -description: >- - Structured decision journals from decisions and context. Use when the user needs a product - workflow for decision making related to structured decision journals from decisions and - context. Trigger terms: pm, decision-making, journaling, forecasting, base-rates. ---- -# Structured decision journals from decisions and context - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured decision journals from decisions and context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DECISION}} -- {{CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: "Structured decision journals from decisions and context". -Success metric: -- Produces a complete decision journal with all required sections filled from provided context. -- Probability estimates are coherent and sum to 100%. -- Quit conditions are measurable and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{DECISION}}` and `{{CONTEXT}}`; if information is missing, state assumptions explicitly. -- Separate facts, assumptions, missing evidence, and risky leaps before forecasting. -- Generate 3-5 expected outcomes spanning best-case to worst-case and covering short-term and long-term effects. -- Provide one probability for each expected outcome; probabilities must total exactly 100%. -- Include the strongest alternative option considered, not only the chosen path. -- Provide 3-5 key assumptions that materially affect outcome validity. -- Provide relevant base rates/statistics tied to this decision type; if unavailable, provide directional proxies and label as assumptions. -- Include disconfirming evidence that would weaken the decision. -- Include a bias checklist for anchoring, availability, confirmation, sunk cost, status quo, optimism, and loss/risk aversion. -- Provide 2-3 measurable quit conditions with clear trigger thresholds. -- Provide a decision review date and owner. -- Keep `` intentionally blank for future updates. - -FORMAT -Return exactly this structure: - - - -[Decision, owner, date, context, and chosen option] - - - -Known facts: -Assumptions: -Missing evidence: -Risky leaps: - - - -1. [Chosen option] -2. [Strongest alternative] -3. [Optional additional alternative] - - - -1. [Outcome] -2. [Outcome] -3. [Outcome] -[Optional 4th and 5th outcome] - - - -1. [Outcome 1] - [X%] -2. [Outcome 2] - [Y%] -3. [Outcome 3] - [Z%] -[Optional 4th and 5th probability] -Total: 100% - - - -1. [Assumption] -2. [Assumption] -3. [Assumption] -[Optional 4th and 5th assumption] - - - -1. [Base rate/statistic + source context or rationale] -2. [Base rate/statistic + source context or rationale] -[Optional additional base rates] - - - -1. [Evidence that would weaken or reverse the decision] -2. [Evidence to seek before/after deciding] - - - -Anchoring: -Availability: -Confirmation: -Sunk cost / escalation: -Status quo: -Optimism: -Loss or risk aversion: - - - -1. [Condition + measurable threshold] -2. [Condition + measurable threshold] -[Optional 3rd condition] - - - - - - -Owner: -Review date: -What would change the decision: - - - -FAILURE -- Any required section in `FORMAT` is missing, malformed, or incomplete. -- Fewer than 3 or more than 5 expected outcomes. -- Probability estimates do not map to outcomes or do not total 100%. -- Fewer than 3 key assumptions or fewer than 2 quit conditions. -- Quit conditions are not measurable. -- No strongest alternative, disconfirming evidence, bias checklist, review owner, or review date. -- Claims are generic or not grounded in provided inputs. -- `` is pre-filled with outcome claims. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-decision-journals-from-decisions-and-context/agents/openai.yaml b/skills/structured-decision-journals-from-decisions-and-context/agents/openai.yaml deleted file mode 100644 index 97c8e9ea..00000000 --- a/skills/structured-decision-journals-from-decisions-and-context/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured decision journals from decisions and context" - short_description: "Structured decision journals from decisions and context. Use when the user needs a product workflow for decision..." - brand_color: "#7C2D12" - default_prompt: "Use $structured-decision-journals-from-decisions-and-context with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-decision-journals-from-decisions-and-context/productize.json b/skills/structured-decision-journals-from-decisions-and-context/productize.json deleted file mode 100644 index e5f6be42..00000000 --- a/skills/structured-decision-journals-from-decisions-and-context/productize.json +++ /dev/null @@ -1,42 +0,0 @@ -{ - "title": "Structured decision journals from decisions and context", - "category": "Decision Making", - "lifecycle": "Think", - "tags": [ - "structured-decision-journals-from-decisions-and-context", - "structured", - "decision", - "journals", - "decisions", - "context" - ], - "use_when": "Use when recording a decision before or immediately after it is made so future review can compare expected outcomes, assumptions, probabilities, base rates, bias risks, quit conditions, and actual results.", - "do_not_use_when": "Do not use Structured decision journals from decisions and context when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Decision journal with decision frame, alternatives, outcomes, probabilities, base rates, disconfirming evidence, bias checklist, quit conditions, and review plan", - "routing_signals": [ - "structured-decision-journals-from-decisions-and-context", - "structured", - "decision", - "journals", - "decisions", - "context", - "assumptions", - "probabilities", - "base-rates", - "bias-risks", - "quit-conditions", - "and-actual-results" - ], - "framework_fit": "Best when the product work is explicitly about decision making and the requested method fits Structured decision journals from decisions and context.", - "failure_modes": [ - "Produces Decision journal with decision frame, alternatives, outcomes, probabilities, base rates, disconfirming evidence, bias checklist, quit conditions, and review plan without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Structured decision journals from decisions and context as generic Decision Making advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured decision journals from decisions and context when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-decision-journals-from-decisions-and-context to record our decision to pause the self-serve onboarding rebuild, including expected outcomes, base rates, bias risks, quit conditions, and review date.", - "expected_artifact": "Decision journal with decision frame, alternatives, outcomes, probabilities, base rates, disconfirming evidence, bias checklist, quit conditions, and review plan" - } - ] -} diff --git a/skills/structured-insight-extraction-from-conversation-transcripts/SKILL.md b/skills/structured-insight-extraction-from-conversation-transcripts/SKILL.md deleted file mode 100644 index 96036500..00000000 --- a/skills/structured-insight-extraction-from-conversation-transcripts/SKILL.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -name: structured-insight-extraction-from-conversation-transcripts -description: >- - Structured insight extraction from conversation transcripts. Use when the user needs a - product workflow for presentation & communication related to structured insight extraction - from conversation transcripts. Trigger terms: conversation-analysis, transcripts, - insight-extraction, presentation, communication. ---- - - - -# Structured insight extraction from conversation transcripts - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-insight-extraction-from-conversation-transcripts` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: Structured insight extraction from conversation transcripts stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Structured insight extraction from conversation transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONVERSATION_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Structured insight extraction from conversation transcripts. -Success metric: -- Produces a faithful, structured reconstruction of the conversation flow and outcomes. -- Identifies participants, branches, responsibilities, current status, and open items. -- Keeps all claims grounded in the transcript without adding assumptions. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CONVERSATION_TRANSCRIPT}}`; do not infer roles or tasks not stated. -- Identify all participants and their roles (if roles are unclear, note `Unknown`). -- Summarize conversation flow and any branching points. -- Capture participant responsibilities and open items explicitly mentioned. -- Keep output strictly within the required tags; no scratchpad in final output. - -FORMAT -Return exactly this structure: - - - -[List of participants and their roles] - - - -[Summary of the conversation's progression] - - - -[List of significant branches or shifts in the conversation] - - - -[Summary of each participant's tasks or responsibilities] - - - -[Summary of where the conversation has landed] - - - -[List of any open questions or tasks] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Participants or responsibilities are inferred without transcript evidence. -- Open items are missing or not tied to the transcript. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-insight-extraction-from-conversation-transcripts/SKILL.md.tmpl b/skills/structured-insight-extraction-from-conversation-transcripts/SKILL.md.tmpl deleted file mode 100644 index 32aabea6..00000000 --- a/skills/structured-insight-extraction-from-conversation-transcripts/SKILL.md.tmpl +++ /dev/null @@ -1,79 +0,0 @@ ---- -name: structured-insight-extraction-from-conversation-transcripts -description: >- - Structured insight extraction from conversation transcripts. Use when the user needs a - product workflow for presentation & communication related to structured insight extraction - from conversation transcripts. Trigger terms: conversation-analysis, transcripts, - insight-extraction, presentation, communication. ---- -# Structured insight extraction from conversation transcripts - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured insight extraction from conversation transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONVERSATION_TRANSCRIPT}} - - -GOAL -Produce a high-quality deliverable for: Structured insight extraction from conversation transcripts. -Success metric: -- Produces a faithful, structured reconstruction of the conversation flow and outcomes. -- Identifies participants, branches, responsibilities, current status, and open items. -- Keeps all claims grounded in the transcript without adding assumptions. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{CONVERSATION_TRANSCRIPT}}`; do not infer roles or tasks not stated. -- Identify all participants and their roles (if roles are unclear, note `Unknown`). -- Summarize conversation flow and any branching points. -- Capture participant responsibilities and open items explicitly mentioned. -- Keep output strictly within the required tags; no scratchpad in final output. - -FORMAT -Return exactly this structure: - - - -[List of participants and their roles] - - - -[Summary of the conversation's progression] - - - -[List of significant branches or shifts in the conversation] - - - -[Summary of each participant's tasks or responsibilities] - - - -[Summary of where the conversation has landed] - - - -[List of any open questions or tasks] - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Participants or responsibilities are inferred without transcript evidence. -- Open items are missing or not tied to the transcript. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-insight-extraction-from-conversation-transcripts/agents/openai.yaml b/skills/structured-insight-extraction-from-conversation-transcripts/agents/openai.yaml deleted file mode 100644 index ac9259ee..00000000 --- a/skills/structured-insight-extraction-from-conversation-transcripts/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured insight extraction from conversation transcripts" - short_description: "Structured insight extraction from conversation transcripts. Use when the user needs a product workflow for..." - brand_color: "#0891B2" - default_prompt: "Use $structured-insight-extraction-from-conversation-transcripts with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-insight-extraction-from-conversation-transcripts/productize.json b/skills/structured-insight-extraction-from-conversation-transcripts/productize.json deleted file mode 100644 index 51eb10b9..00000000 --- a/skills/structured-insight-extraction-from-conversation-transcripts/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Structured insight extraction from conversation transcripts", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "structured-insight-extraction-from-conversation-transcripts", - "structured", - "insight", - "extraction", - "conversation", - "transcripts" - ], - "use_when": "Structured insight extraction from conversation transcripts. Use when the user needs a product workflow for presentation & communication related to structured insight extraction from conversation transcripts. Trigger terms: conversation-analysis, transcripts, insight-extraction, presentation, communication.", - "do_not_use_when": "Do not use Structured insight extraction from conversation transcripts when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Structured insight extraction from conversation transcripts stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "structured-insight-extraction-from-conversation-transcripts", - "structured", - "insight", - "extraction", - "conversation", - "transcripts" - ], - "framework_fit": "Structured insight extraction from conversation transcripts fits Stakeholder Communication work in the Align lifecycle when the user needs Structured insight extraction from conversation transcripts stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Structured insight extraction from conversation transcripts stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats Structured insight extraction from conversation transcripts as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured insight extraction from conversation transcripts when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-insight-extraction-from-conversation-transcripts to turn this structured context into a decision-ready Structured insight extraction from conversation transcripts stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "Structured insight extraction from conversation transcripts stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/structured-interview-notes-from-transcript-using-flexible/SKILL.md b/skills/structured-interview-notes-from-transcript-using-flexible/SKILL.md deleted file mode 100644 index 5c284d16..00000000 --- a/skills/structured-interview-notes-from-transcript-using-flexible/SKILL.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -name: structured-interview-notes-from-transcript-using-flexible -description: >- - Structured interview notes from transcript using flexible frameworks. Use when the user - needs a product workflow for user research related to structured interview notes from - transcript using flexible frameworks. Trigger terms: user-research, interviews, transcripts. ---- - - - -# Structured interview notes from transcript using flexible frameworks - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-interview-notes-from-transcript-using-flexible` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps - -Use this skill to run the Productize prompt contract for **Structured interview notes from transcript using flexible frameworks**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- `{{INTERVIEW_TRANSCRIPT}}`: Source interview transcript. -- `{{NOTE_TAKING_MODE}}`: One of `Chronological`, `Topical`, `AEIOU Framework`, `Empathy Map`. - - -GOAL -Convert interview transcripts into concise, evidence-grounded structured notes using a selected note-taking framework. -Success metric: -- Notes are concise, atomic, and traceable to transcript content. -- Organization strictly follows the selected note-taking mode. -- Output uses the required tagged structure and one-column table format. - -CONSTRAINTS -- Use only provided inputs; if data is unclear, include explicit assumptions inside `` under an `Assumptions` subsection. -- Output only final notes wrapped in `` tags. -- Every note must: -- Capture exactly one idea. -- Be under 250 characters. -- Be grounded in transcript evidence. -- Use one-column markdown tables with clear category headers. -- Apply mode-specific organization: -- `Chronological`: single table ordered by transcript sequence. -- `Topical`: separate tables by major themes. -- `AEIOU Framework`: exactly five tables: Activities, Environments, Interactions, Objects, Users. -- `Empathy Map`: exactly eight tables: Thinks, Feels, Says, Does, Sees, Hears, Pains, Goals. -- If `{{NOTE_TAKING_MODE}}` is invalid or missing, default to `Topical` and record this in `Assumptions`. - -FORMAT -Return exactly this structure: - - -[Mode label] - -[Category Header] -| Note | -| --- | -| [One atomic note under 250 chars] | -| [One atomic note under 250 chars] | - -[Repeat tables according to selected mode] - -Assumptions (only if needed) -| Note | -| --- | -| [Explicit assumption due to missing/ambiguous data] | - - -FAILURE -- `` wrapper is missing or malformed. -- Tables are missing, not one-column, unlabeled, or not aligned with selected/default mode. -- Required mode categories are missing (AEIOU or Empathy Map). -- Notes exceed 250 characters, combine multiple ideas, or are not transcript-grounded. -- Output includes analysis/explanations outside structured notes. -- Assumptions are needed but not explicitly listed. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `summarize interview`, `interview notes`, `satisfaction signals`, `action items`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/structured-interview-notes-from-transcript-using-flexible/SKILL.md.tmpl b/skills/structured-interview-notes-from-transcript-using-flexible/SKILL.md.tmpl deleted file mode 100644 index d33fb064..00000000 --- a/skills/structured-interview-notes-from-transcript-using-flexible/SKILL.md.tmpl +++ /dev/null @@ -1,82 +0,0 @@ ---- -name: structured-interview-notes-from-transcript-using-flexible -description: >- - Structured interview notes from transcript using flexible frameworks. Use when the user - needs a product workflow for user research related to structured interview notes from - transcript using flexible frameworks. Trigger terms: user-research, interviews, transcripts. ---- -# Structured interview notes from transcript using flexible frameworks - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured interview notes from transcript using flexible frameworks**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- `{{INTERVIEW_TRANSCRIPT}}`: Source interview transcript. -- `{{NOTE_TAKING_MODE}}`: One of `Chronological`, `Topical`, `AEIOU Framework`, `Empathy Map`. - - -GOAL -Convert interview transcripts into concise, evidence-grounded structured notes using a selected note-taking framework. -Success metric: -- Notes are concise, atomic, and traceable to transcript content. -- Organization strictly follows the selected note-taking mode. -- Output uses the required tagged structure and one-column table format. - -CONSTRAINTS -- Use only provided inputs; if data is unclear, include explicit assumptions inside `` under an `Assumptions` subsection. -- Output only final notes wrapped in `` tags. -- Every note must: -- Capture exactly one idea. -- Be under 250 characters. -- Be grounded in transcript evidence. -- Use one-column markdown tables with clear category headers. -- Apply mode-specific organization: -- `Chronological`: single table ordered by transcript sequence. -- `Topical`: separate tables by major themes. -- `AEIOU Framework`: exactly five tables: Activities, Environments, Interactions, Objects, Users. -- `Empathy Map`: exactly eight tables: Thinks, Feels, Says, Does, Sees, Hears, Pains, Goals. -- If `{{NOTE_TAKING_MODE}}` is invalid or missing, default to `Topical` and record this in `Assumptions`. - -FORMAT -Return exactly this structure: - - -[Mode label] - -[Category Header] -| Note | -| --- | -| [One atomic note under 250 chars] | -| [One atomic note under 250 chars] | - -[Repeat tables according to selected mode] - -Assumptions (only if needed) -| Note | -| --- | -| [Explicit assumption due to missing/ambiguous data] | - - -FAILURE -- `` wrapper is missing or malformed. -- Tables are missing, not one-column, unlabeled, or not aligned with selected/default mode. -- Required mode categories are missing (AEIOU or Empathy Map). -- Notes exceed 250 characters, combine multiple ideas, or are not transcript-grounded. -- Output includes analysis/explanations outside structured notes. -- Assumptions are needed but not explicitly listed. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `summarize interview`, `interview notes`, `satisfaction signals`, `action items`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/structured-interview-notes-from-transcript-using-flexible/agents/openai.yaml b/skills/structured-interview-notes-from-transcript-using-flexible/agents/openai.yaml deleted file mode 100644 index c9b39b5a..00000000 --- a/skills/structured-interview-notes-from-transcript-using-flexible/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured interview notes from transcript using flexible frameworks" - short_description: "Structured interview notes from transcript using flexible frameworks. Use when the user needs a product workflow for..." - brand_color: "#0D9488" - default_prompt: "Use $structured-interview-notes-from-transcript-using-flexible with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-interview-notes-from-transcript-using-flexible/productize.json b/skills/structured-interview-notes-from-transcript-using-flexible/productize.json deleted file mode 100644 index e26f06c9..00000000 --- a/skills/structured-interview-notes-from-transcript-using-flexible/productize.json +++ /dev/null @@ -1,47 +0,0 @@ -{ - "title": "Structured interview notes from transcript using flexible frameworks", - "category": "Discovery", - "lifecycle": "Discover", - "tags": [ - "structured-interview-notes-from-transcript-using-flexible", - "structured", - "interview", - "notes", - "transcript", - "flexible", - "summarize-interview", - "interview-notes", - "satisfaction-signals", - "action-items" - ], - "use_when": "Structured interview notes from transcript using flexible frameworks. Use when the user needs a product workflow for user research related to structured interview notes from transcript using flexible frameworks. Trigger terms: user-research, interviews, transcripts.", - "do_not_use_when": "Do not use Structured interview notes from transcript using flexible frameworks when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "structured-interview-notes-from-transcript-using-flexible", - "structured", - "interview", - "notes", - "transcript", - "flexible", - "summarize-interview", - "interview-notes", - "satisfaction-signals", - "action-items" - ], - "framework_fit": "Structured interview notes from transcript using flexible frameworks fits Discovery work in the Discover lifecycle when the user needs Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Structured interview notes from transcript using flexible frameworks as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured interview notes from transcript using flexible frameworks when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-interview-notes-from-transcript-using-flexible to turn this structured context into a decision-ready Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Structured interview notes from transcript using flexible frameworks research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ], - "references": [ - "references/pm-skills-main-merge.md" - ] -} diff --git a/skills/structured-interview-notes-from-transcript-using-flexible/references/pm-skills-main-merge.md b/skills/structured-interview-notes-from-transcript-using-flexible/references/pm-skills-main-merge.md deleted file mode 100644 index 5b72dc8c..00000000 --- a/skills/structured-interview-notes-from-transcript-using-flexible/references/pm-skills-main-merge.md +++ /dev/null @@ -1,61 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to make interview transcript summaries include JTBD, satisfaction signals, quotes, and action items. - -## Routing Signals - -- summarize interview -- interview notes -- satisfaction signals -- action items - -## pm-product-discovery/skills/summarize-interview/SKILL.md - -## Summarize Customer Interview - -Transform an interview transcript into a structured summary focused on Jobs to Be Done, satisfaction, and action items. - -### Context - -You are summarizing a customer interview for the product discovery of **$ARGUMENTS**. - -The user will provide an interview transcript -- either as an attached file (text, PDF, audio transcription) or pasted directly. Read any attached files first. - -### Instructions - -1. **Read the full transcript** carefully before summarizing. - -2. **Fill in the summary template** below. Use "-" if information is unavailable. Replace numeric values with qualitative descriptions if needed (e.g., "not satisfied"). - -3. **Use clear, simple language** -- a primary school graduate should be able to understand the summary. - -### Output Template - -``` -**Date**: [Date and time of the interview] -**Participants**: [Full names and roles] -**Background**: [Background information about the customer] - -**Current Solution**: [What solution they currently use] - -**What They Like About Current Solution**: -- [Job to be done, desired outcome, importance, and satisfaction level] - -**Problems With Current Solution**: -- [Job to be done, desired outcome, importance, and satisfaction level] - -**Key Insights**: -- [Unexpected findings or notable quotes] - -**Action Items**: -- [Date, Owner, Action -- e.g., "2025-01-15, Pawe Huryn, Follow up with customer about pricing"] -``` - -Save the summary as a markdown document in the user's workspace. - ---- - -### Further Reading - -- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate) -- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course) diff --git a/skills/structured-json-descriptions-from-ui-screenshots/SKILL.md b/skills/structured-json-descriptions-from-ui-screenshots/SKILL.md deleted file mode 100644 index f5d32694..00000000 --- a/skills/structured-json-descriptions-from-ui-screenshots/SKILL.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -name: structured-json-descriptions-from-ui-screenshots -description: >- - Structured JSON descriptions from UI screenshots. Use when the user needs a product workflow - for design & prototyping related to structured json descriptions from ui screenshots. - Trigger terms: pm, ux, design, ui, json. ---- - - - -# Structured JSON descriptions from UI screenshots - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-json-descriptions-from-ui-screenshots` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: Structured JSON descriptions from UI screenshots UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Structured JSON descriptions from UI screenshots**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SCREENSHOT}} - - -GOAL -Produce a high-quality deliverable for: "Structured JSON descriptions from UI screenshots". -Success metric: -- Produces a detailed, structured JSON description of the UI screenshot. -- Captures layout, visual style, text, UI elements, imagery/icons, and hierarchy with high fidelity. -- Flags ambiguities explicitly without inventing unsupported details. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{SCREENSHOT}}`; if details are unclear, state uncertainty in `notes`. -- Do not invent hidden functionality or off-screen content. -- Capture: - - overall layout and structure, - - color scheme, - - UI elements (interactive and non-interactive), - - text content, - - images/icons, - - hierarchy/positioning. -- For each `ui_elements` item include `type`, `content`, `position`, and `style`. -- Keep output as valid JSON only inside `` tags (no prose outside JSON). - -FORMAT -Return exactly this structure: - - -{ - "overall_layout": { - "description": "", - "main_sections": [] - }, - "color_scheme": { - "primary_colors": [], - "secondary_colors": [], - "background_color": "" - }, - "ui_elements": [ - { - "type": "", - "content": "", - "position": "", - "style": {} - } - ], - "text_content": [ - { - "type": "", - "content": "", - "position": "" - } - ], - "images_and_icons": [ - { - "type": "", - "description": "", - "position": "" - } - ], - "notes": [] -} - - -FAILURE -- Output is not wrapped in `` tags. -- JSON is invalid or required top-level keys are missing. -- `ui_elements` entries are missing `type`, `content`, `position`, or `style`. -- Observations are generic and not grounded in visible screenshot evidence. -- Ambiguities exist but `notes` is omitted. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-json-descriptions-from-ui-screenshots/SKILL.md.tmpl b/skills/structured-json-descriptions-from-ui-screenshots/SKILL.md.tmpl deleted file mode 100644 index 67c4504b..00000000 --- a/skills/structured-json-descriptions-from-ui-screenshots/SKILL.md.tmpl +++ /dev/null @@ -1,97 +0,0 @@ ---- -name: structured-json-descriptions-from-ui-screenshots -description: >- - Structured JSON descriptions from UI screenshots. Use when the user needs a product workflow - for design & prototyping related to structured json descriptions from ui screenshots. - Trigger terms: pm, ux, design, ui, json. ---- -# Structured JSON descriptions from UI screenshots - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured JSON descriptions from UI screenshots**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SCREENSHOT}} - - -GOAL -Produce a high-quality deliverable for: "Structured JSON descriptions from UI screenshots". -Success metric: -- Produces a detailed, structured JSON description of the UI screenshot. -- Captures layout, visual style, text, UI elements, imagery/icons, and hierarchy with high fidelity. -- Flags ambiguities explicitly without inventing unsupported details. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{SCREENSHOT}}`; if details are unclear, state uncertainty in `notes`. -- Do not invent hidden functionality or off-screen content. -- Capture: - - overall layout and structure, - - color scheme, - - UI elements (interactive and non-interactive), - - text content, - - images/icons, - - hierarchy/positioning. -- For each `ui_elements` item include `type`, `content`, `position`, and `style`. -- Keep output as valid JSON only inside `` tags (no prose outside JSON). - -FORMAT -Return exactly this structure: - - -{ - "overall_layout": { - "description": "", - "main_sections": [] - }, - "color_scheme": { - "primary_colors": [], - "secondary_colors": [], - "background_color": "" - }, - "ui_elements": [ - { - "type": "", - "content": "", - "position": "", - "style": {} - } - ], - "text_content": [ - { - "type": "", - "content": "", - "position": "" - } - ], - "images_and_icons": [ - { - "type": "", - "description": "", - "position": "" - } - ], - "notes": [] -} - - -FAILURE -- Output is not wrapped in `` tags. -- JSON is invalid or required top-level keys are missing. -- `ui_elements` entries are missing `type`, `content`, `position`, or `style`. -- Observations are generic and not grounded in visible screenshot evidence. -- Ambiguities exist but `notes` is omitted. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-json-descriptions-from-ui-screenshots/agents/openai.yaml b/skills/structured-json-descriptions-from-ui-screenshots/agents/openai.yaml deleted file mode 100644 index f28202f6..00000000 --- a/skills/structured-json-descriptions-from-ui-screenshots/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured JSON descriptions from UI screenshots" - short_description: "Structured JSON descriptions from UI screenshots. Use when the user needs a product workflow for design &..." - brand_color: "#DB2777" - default_prompt: "Use $structured-json-descriptions-from-ui-screenshots with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-json-descriptions-from-ui-screenshots/productize.json b/skills/structured-json-descriptions-from-ui-screenshots/productize.json deleted file mode 100644 index 8bb09d29..00000000 --- a/skills/structured-json-descriptions-from-ui-screenshots/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Structured JSON descriptions from UI screenshots", - "category": "Design", - "lifecycle": "Design", - "tags": [ - "structured-json-descriptions-from-ui-screenshots", - "structured", - "json", - "descriptions", - "screenshots", - "design", - "prototyping" - ], - "use_when": "Structured JSON descriptions from UI screenshots. Use when the user needs a product workflow for design & prototyping related to structured json descriptions from ui screenshots. Trigger terms: pm, ux, design, ui, json.", - "do_not_use_when": "Do not use Structured JSON descriptions from UI screenshots when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Structured JSON descriptions from UI screenshots UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "structured-json-descriptions-from-ui-screenshots", - "structured", - "json", - "descriptions", - "screenshots", - "design", - "prototyping" - ], - "framework_fit": "Structured JSON descriptions from UI screenshots fits Design work in the Design lifecycle when the user needs Structured JSON descriptions from UI screenshots UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Structured JSON descriptions from UI screenshots UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Structured JSON descriptions from UI screenshots as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured JSON descriptions from UI screenshots when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-json-descriptions-from-ui-screenshots to turn this structured context into a decision-ready Structured JSON descriptions from UI screenshots UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Structured JSON descriptions from UI screenshots UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/structured-product-hypotheses-from-product-problems/SKILL.md b/skills/structured-product-hypotheses-from-product-problems/SKILL.md deleted file mode 100644 index 9eceee9f..00000000 --- a/skills/structured-product-hypotheses-from-product-problems/SKILL.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -name: structured-product-hypotheses-from-product-problems -description: >- - Structured product hypotheses from product problems. Use when the user needs a product - workflow for decision making related to structured product hypotheses from product problems. - Trigger terms: pm, decision-making, experimentation, hypotheses, product. ---- - - - -# Structured product hypotheses from product problems - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-product-hypotheses-from-product-problems` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Structured product hypotheses from product problems product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Structured product hypotheses from product problems**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_PROBLEM}} - - -GOAL -Produce a high-quality deliverable for: "Structured product hypotheses from product problems". -Success metric: -- Produces a clear, testable product hypothesis directly tied to the provided problem. -- Includes a measurable plan to evaluate success with explicit metrics and thresholds. -- Covers all required hypothesis-formation steps before finalizing the hypothesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_PROBLEM}}`; if details are missing, state assumptions explicitly. -- Execute all six steps: experiment goal, draft hypothesis, specificity check, measurement plan, validate/refine, narrative framing. -- Draft hypothesis must include all five components: Action, Outcome, Direction, Users, Conditions. -- Keep outcomes measurable; avoid vague terms (for example: "better", "improve") without quantification. -- Ensure the final hypothesis and metrics are realistic and testable in product-experiment contexts. - -FORMAT -Return exactly this structure: - - -[User problem and proposed change] - - - -[Action] will cause [Outcome] to [Direction] for [Users] under [Conditions]. - - - -- Action clarity: [Pass/Fail + note] -- Outcome clarity: [Pass/Fail + note] -- Direction clarity: [Pass/Fail + note] -- Users clarity: [Pass/Fail + note] -- Conditions clarity: [Pass/Fail + note] - - - -- Primary metric: [Metric + baseline + target change + timeframe] -- Secondary metrics: [Metric list] -- Data collection: [How/where measured] -- Guardrails: [Risk metrics to monitor] - - - -- Clarity gaps found: [List] -- Refinements made: [List] - - - -[Short story-style framing linking problem -> change -> expected outcome -> evidence of success] - - - -Currently, [user] is experiencing [problem]. -We believe that by [change], we'll see [outcome]. -We'll know we're right when [metric] changes by [amount]. - - - -[Brief explanation of why this hypothesis fits the product problem and framework] - - -FAILURE -- Any required section in `FORMAT` is missing, malformed, or incomplete. -- Hypothesis draft omits any of the five required components. -- Measurement plan lacks metric, target change, or timeframe. -- Final `` does not follow the required three-line template. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-product-hypotheses-from-product-problems/SKILL.md.tmpl b/skills/structured-product-hypotheses-from-product-problems/SKILL.md.tmpl deleted file mode 100644 index 099eba94..00000000 --- a/skills/structured-product-hypotheses-from-product-problems/SKILL.md.tmpl +++ /dev/null @@ -1,95 +0,0 @@ ---- -name: structured-product-hypotheses-from-product-problems -description: >- - Structured product hypotheses from product problems. Use when the user needs a product - workflow for decision making related to structured product hypotheses from product problems. - Trigger terms: pm, decision-making, experimentation, hypotheses, product. ---- -# Structured product hypotheses from product problems - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured product hypotheses from product problems**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_PROBLEM}} - - -GOAL -Produce a high-quality deliverable for: "Structured product hypotheses from product problems". -Success metric: -- Produces a clear, testable product hypothesis directly tied to the provided problem. -- Includes a measurable plan to evaluate success with explicit metrics and thresholds. -- Covers all required hypothesis-formation steps before finalizing the hypothesis. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_PROBLEM}}`; if details are missing, state assumptions explicitly. -- Execute all six steps: experiment goal, draft hypothesis, specificity check, measurement plan, validate/refine, narrative framing. -- Draft hypothesis must include all five components: Action, Outcome, Direction, Users, Conditions. -- Keep outcomes measurable; avoid vague terms (for example: "better", "improve") without quantification. -- Ensure the final hypothesis and metrics are realistic and testable in product-experiment contexts. - -FORMAT -Return exactly this structure: - - -[User problem and proposed change] - - - -[Action] will cause [Outcome] to [Direction] for [Users] under [Conditions]. - - - -- Action clarity: [Pass/Fail + note] -- Outcome clarity: [Pass/Fail + note] -- Direction clarity: [Pass/Fail + note] -- Users clarity: [Pass/Fail + note] -- Conditions clarity: [Pass/Fail + note] - - - -- Primary metric: [Metric + baseline + target change + timeframe] -- Secondary metrics: [Metric list] -- Data collection: [How/where measured] -- Guardrails: [Risk metrics to monitor] - - - -- Clarity gaps found: [List] -- Refinements made: [List] - - - -[Short story-style framing linking problem -> change -> expected outcome -> evidence of success] - - - -Currently, [user] is experiencing [problem]. -We believe that by [change], we'll see [outcome]. -We'll know we're right when [metric] changes by [amount]. - - - -[Brief explanation of why this hypothesis fits the product problem and framework] - - -FAILURE -- Any required section in `FORMAT` is missing, malformed, or incomplete. -- Hypothesis draft omits any of the five required components. -- Measurement plan lacks metric, target change, or timeframe. -- Final `` does not follow the required three-line template. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-product-hypotheses-from-product-problems/agents/openai.yaml b/skills/structured-product-hypotheses-from-product-problems/agents/openai.yaml deleted file mode 100644 index 88785083..00000000 --- a/skills/structured-product-hypotheses-from-product-problems/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured product hypotheses from product problems" - short_description: "Structured product hypotheses from product problems. Use when the user needs a product workflow for decision making..." - brand_color: "#0D9488" - default_prompt: "Use $structured-product-hypotheses-from-product-problems with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-product-hypotheses-from-product-problems/productize.json b/skills/structured-product-hypotheses-from-product-problems/productize.json deleted file mode 100644 index 190eda8a..00000000 --- a/skills/structured-product-hypotheses-from-product-problems/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Structured product hypotheses from product problems", - "category": "Discovery", - "lifecycle": "Think", - "tags": [ - "structured-product-hypotheses-from-product-problems", - "structured", - "hypotheses", - "problems", - "decision", - "making", - "discovery" - ], - "use_when": "Structured product hypotheses from product problems. Use when the user needs a product workflow for decision making related to structured product hypotheses from product problems. Trigger terms: pm, decision-making, experimentation, hypotheses, product.", - "do_not_use_when": "Do not use Structured product hypotheses from product problems when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Structured product hypotheses from product problems product artifact with evidence, risks, recommendation, and next action", - "routing_signals": [ - "structured-product-hypotheses-from-product-problems", - "structured", - "hypotheses", - "problems", - "decision", - "making", - "discovery" - ], - "framework_fit": "Structured product hypotheses from product problems fits Discovery work in the Think lifecycle when the user needs Structured product hypotheses from product problems product artifact with evidence, risks, recommendation, and next action and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Structured product hypotheses from product problems product artifact with evidence, risks, recommendation, and next action without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Structured product hypotheses from product problems as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured product hypotheses from product problems when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-product-hypotheses-from-product-problems to turn this structured context into a decision-ready Structured product hypotheses from product problems product artifact with evidence, risks, recommendation, and next action.", - "expected_artifact": "Structured product hypotheses from product problems product artifact with evidence, risks, recommendation, and next action" - } - ] -} diff --git a/skills/structured-product-strategy-from-product-context/SKILL.md b/skills/structured-product-strategy-from-product-context/SKILL.md deleted file mode 100644 index 804867a5..00000000 --- a/skills/structured-product-strategy-from-product-context/SKILL.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -name: structured-product-strategy-from-product-context -description: >- - Structured product strategy from product context. Use when the user needs a product workflow - for product strategy related to structured product strategy from product context. Trigger - terms: product-strategy, roadmapping, product-management, structured-thinking, - product-vision. ---- - - - -# Structured product strategy from product context - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-product-strategy-from-product-context` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Structured product strategy from product context strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Structured product strategy from product context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Structured product strategy from product context. -Success metric: -- Produces a complete strategy across objective, users, superpowers, vision, pillars, impact, and roadmap. -- Keeps each section grounded in the provided product context. -- Provides concrete, coherent outputs that build on each other. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_CONTEXT}}`; if context is missing, state assumptions explicitly. -- Provide all 7 sections in the required format. -- Objective: 1โ€“2 sentences, ambitious but achievable. -- Users: 1โ€“2 groups; each with 3โ€“4 needs. -- Superpowers: 3โ€“4 unique advantages. -- Vision: 2โ€“3 paragraphs. -- Pillars: 2โ€“4 themes with brief descriptions. -- Impact: causal mechanism or back-of-envelope logic. -- Roadmap: 3โ€“10 items per pillar (no prioritization). - -FORMAT -Return exactly this structure: - - - - - -[Your objective here] - - - - - -[User group descriptions and bullet points here] - - - - - -[List of superpowers here] - - - - - -[Your vision paragraphs here] - - - - - -[List of pillars with titles and descriptions here] - - - - - -[Impact description here] - - - - - -[Roadmap items for each pillar here] - - - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Counts are outside required ranges (users, superpowers, pillars, roadmap items). -- Impact does not explain mechanism or is generic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-product-strategy-from-product-context/SKILL.md.tmpl b/skills/structured-product-strategy-from-product-context/SKILL.md.tmpl deleted file mode 100644 index 70b7da86..00000000 --- a/skills/structured-product-strategy-from-product-context/SKILL.md.tmpl +++ /dev/null @@ -1,103 +0,0 @@ ---- -name: structured-product-strategy-from-product-context -description: >- - Structured product strategy from product context. Use when the user needs a product workflow - for product strategy related to structured product strategy from product context. Trigger - terms: product-strategy, roadmapping, product-management, structured-thinking, - product-vision. ---- -# Structured product strategy from product context - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured product strategy from product context**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_CONTEXT}} - - -GOAL -Produce a high-quality deliverable for: Structured product strategy from product context. -Success metric: -- Produces a complete strategy across objective, users, superpowers, vision, pillars, impact, and roadmap. -- Keeps each section grounded in the provided product context. -- Provides concrete, coherent outputs that build on each other. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_CONTEXT}}`; if context is missing, state assumptions explicitly. -- Provide all 7 sections in the required format. -- Objective: 1โ€“2 sentences, ambitious but achievable. -- Users: 1โ€“2 groups; each with 3โ€“4 needs. -- Superpowers: 3โ€“4 unique advantages. -- Vision: 2โ€“3 paragraphs. -- Pillars: 2โ€“4 themes with brief descriptions. -- Impact: causal mechanism or back-of-envelope logic. -- Roadmap: 3โ€“10 items per pillar (no prioritization). - -FORMAT -Return exactly this structure: - - - - - -[Your objective here] - - - - - -[User group descriptions and bullet points here] - - - - - -[List of superpowers here] - - - - - -[Your vision paragraphs here] - - - - - -[List of pillars with titles and descriptions here] - - - - - -[Impact description here] - - - - - -[Roadmap items for each pillar here] - - - - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Counts are outside required ranges (users, superpowers, pillars, roadmap items). -- Impact does not explain mechanism or is generic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-product-strategy-from-product-context/agents/openai.yaml b/skills/structured-product-strategy-from-product-context/agents/openai.yaml deleted file mode 100644 index 600dd790..00000000 --- a/skills/structured-product-strategy-from-product-context/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured product strategy from product context" - short_description: "Structured product strategy from product context. Use when the user needs a product workflow for product strategy..." - brand_color: "#059669" - default_prompt: "Use $structured-product-strategy-from-product-context with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-product-strategy-from-product-context/productize.json b/skills/structured-product-strategy-from-product-context/productize.json deleted file mode 100644 index a7c5b2d8..00000000 --- a/skills/structured-product-strategy-from-product-context/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Structured product strategy from product context", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "structured-product-strategy-from-product-context", - "structured", - "context", - "use", - "needs", - "workflow" - ], - "use_when": "Structured product strategy from product context. Use when the user needs a product workflow for product strategy related to structured product strategy from product context. Trigger terms: product-strategy, roadmapping, product-management, structured-thinking, product-vision.", - "do_not_use_when": "Do not use Structured product strategy from product context when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Structured product strategy from product context strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "structured-product-strategy-from-product-context", - "structured", - "context", - "use", - "needs", - "workflow" - ], - "framework_fit": "Structured product strategy from product context fits Strategy work in the Strategize lifecycle when the user needs Structured product strategy from product context strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Structured product strategy from product context strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Structured product strategy from product context as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured product strategy from product context when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-product-strategy-from-product-context to turn this structured context into a decision-ready Structured product strategy from product context strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Structured product strategy from product context strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/structured-requirements-from-conversation-transcripts/SKILL.md b/skills/structured-requirements-from-conversation-transcripts/SKILL.md deleted file mode 100644 index fc988f81..00000000 --- a/skills/structured-requirements-from-conversation-transcripts/SKILL.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -name: structured-requirements-from-conversation-transcripts -description: >- - Structured requirements from conversation transcripts. Use when the user needs a product - workflow for business analysis related to structured requirements from conversation - transcripts. Trigger terms: pm, business-analysis, requirements, analysis, transcripts. ---- - - - -# Structured requirements from conversation transcripts - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-requirements-from-conversation-transcripts` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Structured requirements from conversation transcripts delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Structured requirements from conversation transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONVERSATION_TRANSCRIPT}} -- {{CONTEXT}} - - -GOAL -Convert `CONVERSATION_TRANSCRIPT` (+ `CONTEXT`) into a MECE-structured requirements set, then provide a rigorous self-critique of extraction quality. -Success metric: -- Requirements are clear, actionable, and grouped with MECE logic. -- Each requirement is source-traceable and includes dependency/relationship notes where relevant. -- Self-criticism identifies weaknesses without proposing solutions. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip these analysis steps: - 1. Identify explicit requests, constraints, concerns, and implied needs. - 2. Organize requirements into MECE categories / issue-tree logic. - 3. Write requirements in precise, actionable language. - 4. Annotate source traceability and dependency relationships. -- Keep language unambiguous and implementation-relevant without over-specifying design/engineering internals. -- In self-criticism, identify issues only; do not propose fixes. -- Explicitly label assumptions inferred from context. - -FORMAT -Return exactly this structure: - - -[Main themes and scope] -[MECE categories and issue-tree structure] -[Numbered requirements per category with source/dependency notes] -[Cross-references between requirements] -[Implied assumptions not explicitly stated in transcript] - - -[List only] -[List only] -[List only] -[List only] -[List only] -[List only] - - -FAILURE -- Any required schema section is missing or malformed. -- Requirements are generic, non-actionable, or not traceable to transcript/context. -- MECE structure is absent or internally overlapping/confusing. -- Self-criticism includes solution proposals instead of issue identification only. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-requirements-from-conversation-transcripts/SKILL.md.tmpl b/skills/structured-requirements-from-conversation-transcripts/SKILL.md.tmpl deleted file mode 100644 index 6e574f92..00000000 --- a/skills/structured-requirements-from-conversation-transcripts/SKILL.md.tmpl +++ /dev/null @@ -1,74 +0,0 @@ ---- -name: structured-requirements-from-conversation-transcripts -description: >- - Structured requirements from conversation transcripts. Use when the user needs a product - workflow for business analysis related to structured requirements from conversation - transcripts. Trigger terms: pm, business-analysis, requirements, analysis, transcripts. ---- -# Structured requirements from conversation transcripts - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured requirements from conversation transcripts**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{CONVERSATION_TRANSCRIPT}} -- {{CONTEXT}} - - -GOAL -Convert `CONVERSATION_TRANSCRIPT` (+ `CONTEXT`) into a MECE-structured requirements set, then provide a rigorous self-critique of extraction quality. -Success metric: -- Requirements are clear, actionable, and grouped with MECE logic. -- Each requirement is source-traceable and includes dependency/relationship notes where relevant. -- Self-criticism identifies weaknesses without proposing solutions. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip these analysis steps: - 1. Identify explicit requests, constraints, concerns, and implied needs. - 2. Organize requirements into MECE categories / issue-tree logic. - 3. Write requirements in precise, actionable language. - 4. Annotate source traceability and dependency relationships. -- Keep language unambiguous and implementation-relevant without over-specifying design/engineering internals. -- In self-criticism, identify issues only; do not propose fixes. -- Explicitly label assumptions inferred from context. - -FORMAT -Return exactly this structure: - - -[Main themes and scope] -[MECE categories and issue-tree structure] -[Numbered requirements per category with source/dependency notes] -[Cross-references between requirements] -[Implied assumptions not explicitly stated in transcript] - - -[List only] -[List only] -[List only] -[List only] -[List only] -[List only] - - -FAILURE -- Any required schema section is missing or malformed. -- Requirements are generic, non-actionable, or not traceable to transcript/context. -- MECE structure is absent or internally overlapping/confusing. -- Self-criticism includes solution proposals instead of issue identification only. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-requirements-from-conversation-transcripts/agents/openai.yaml b/skills/structured-requirements-from-conversation-transcripts/agents/openai.yaml deleted file mode 100644 index 090d0934..00000000 --- a/skills/structured-requirements-from-conversation-transcripts/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured requirements from conversation transcripts" - short_description: "Structured requirements from conversation transcripts. Use when the user needs a product workflow for business..." - brand_color: "#4F46E5" - default_prompt: "Use $structured-requirements-from-conversation-transcripts with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-requirements-from-conversation-transcripts/productize.json b/skills/structured-requirements-from-conversation-transcripts/productize.json deleted file mode 100644 index 4e35d22e..00000000 --- a/skills/structured-requirements-from-conversation-transcripts/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Structured requirements from conversation transcripts", - "category": "Delivery", - "lifecycle": "Plan", - "tags": [ - "structured-requirements-from-conversation-transcripts", - "structured", - "requirements", - "conversation", - "transcripts", - "business", - "delivery" - ], - "use_when": "Structured requirements from conversation transcripts. Use when the user needs a product workflow for business analysis related to structured requirements from conversation transcripts. Trigger terms: pm, business-analysis, requirements, analysis, transcripts.", - "do_not_use_when": "Do not use Structured requirements from conversation transcripts when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Structured requirements from conversation transcripts delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "structured-requirements-from-conversation-transcripts", - "structured", - "requirements", - "conversation", - "transcripts", - "business", - "delivery" - ], - "framework_fit": "Appropriate when sales calls, discovery notes, meetings, or design-review transcripts need to become requirements, PRD input, acceptance criteria, or delivery scope.", - "failure_modes": [ - "Produces Structured requirements from conversation transcripts delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Structured requirements from conversation transcripts as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured requirements from conversation transcripts when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-requirements-from-conversation-transcripts to turn this structured context into a decision-ready Structured requirements from conversation transcripts delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Structured requirements from conversation transcripts delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/structured-requirements-from-design-assets/SKILL.md b/skills/structured-requirements-from-design-assets/SKILL.md deleted file mode 100644 index faf3874d..00000000 --- a/skills/structured-requirements-from-design-assets/SKILL.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -name: structured-requirements-from-design-assets -description: >- - Structured requirements from design assets. Use when the user needs a product workflow for - business analysis related to structured requirements from design assets. Trigger terms: pm, - business-analysis, requirements, design. ---- - - - -# Structured requirements from design assets - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `structured-requirements-from-design-assets` -- **Lifecycle**: Design -- **Category**: Delivery -- **Primary artifact**: Structured requirements from design assets UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Structured requirements from design assets**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{IMAGE}} - - -GOAL -Translate `IMAGE` design assets into actionable, testable product requirements and acceptance criteria. -Success metric: -- Produces clear, numbered user stories/requirements covering key flows and behaviors shown or implied in the design. -- Provides detailed acceptance criteria mapped to each requirement. -- Keeps requirements implementation-agnostic (focus on "what", not "how"). -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip analysis of visual structure, information hierarchy, interactions, states, and implied business rules. -- Number each requirement/story and keep it measurable and implementation-agnostic. -- Acceptance criteria must map to requirements explicitly (by requirement number/id). -- Include inferred assumptions only when necessary and label them clearly. -- Do not include internal reasoning tags like `` in final output. - -FORMAT -Return exactly this structure: - - - -[List numbered user stories or requirements here] - - - -[List detailed acceptance criteria for each user story or requirement here] - - - -FAILURE -- Required schema is missing or malformed. -- Requirements are generic, non-measurable, or not grounded in the design asset. -- Acceptance criteria are missing, vague, or not mapped to requirements. -- Output contains implementation-detail overreach instead of product requirements. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-requirements-from-design-assets/SKILL.md.tmpl b/skills/structured-requirements-from-design-assets/SKILL.md.tmpl deleted file mode 100644 index 266302e7..00000000 --- a/skills/structured-requirements-from-design-assets/SKILL.md.tmpl +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: structured-requirements-from-design-assets -description: >- - Structured requirements from design assets. Use when the user needs a product workflow for - business analysis related to structured requirements from design assets. Trigger terms: pm, - business-analysis, requirements, design. ---- -# Structured requirements from design assets - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Structured requirements from design assets**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{IMAGE}} - - -GOAL -Translate `IMAGE` design assets into actionable, testable product requirements and acceptance criteria. -Success metric: -- Produces clear, numbered user stories/requirements covering key flows and behaviors shown or implied in the design. -- Provides detailed acceptance criteria mapped to each requirement. -- Keeps requirements implementation-agnostic (focus on "what", not "how"). -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip analysis of visual structure, information hierarchy, interactions, states, and implied business rules. -- Number each requirement/story and keep it measurable and implementation-agnostic. -- Acceptance criteria must map to requirements explicitly (by requirement number/id). -- Include inferred assumptions only when necessary and label them clearly. -- Do not include internal reasoning tags like `` in final output. - -FORMAT -Return exactly this structure: - - - -[List numbered user stories or requirements here] - - - -[List detailed acceptance criteria for each user story or requirement here] - - - -FAILURE -- Required schema is missing or malformed. -- Requirements are generic, non-measurable, or not grounded in the design asset. -- Acceptance criteria are missing, vague, or not mapped to requirements. -- Output contains implementation-detail overreach instead of product requirements. -- Assumptions are used but not explicitly stated. diff --git a/skills/structured-requirements-from-design-assets/agents/openai.yaml b/skills/structured-requirements-from-design-assets/agents/openai.yaml deleted file mode 100644 index 88bb392e..00000000 --- a/skills/structured-requirements-from-design-assets/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Structured requirements from design assets" - short_description: "Structured requirements from design assets. Use when the user needs a product workflow for business analysis related..." - brand_color: "#4F46E5" - default_prompt: "Use $structured-requirements-from-design-assets with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/structured-requirements-from-design-assets/productize.json b/skills/structured-requirements-from-design-assets/productize.json deleted file mode 100644 index bd214a15..00000000 --- a/skills/structured-requirements-from-design-assets/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Structured requirements from design assets", - "category": "Delivery", - "lifecycle": "Design", - "tags": [ - "structured-requirements-from-design-assets", - "structured", - "requirements", - "design", - "assets", - "business", - "delivery" - ], - "use_when": "Structured requirements from design assets. Use when the user needs a product workflow for business analysis related to structured requirements from design assets. Trigger terms: pm, business-analysis, requirements, design.", - "do_not_use_when": "Do not use Structured requirements from design assets when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Structured requirements from design assets UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "structured-requirements-from-design-assets", - "structured", - "requirements", - "design", - "assets", - "business", - "delivery" - ], - "framework_fit": "Structured requirements from design assets fits Delivery work in the Design lifecycle when the user needs Structured requirements from design assets UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Structured requirements from design assets UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Structured requirements from design assets as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Structured requirements from design assets when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $structured-requirements-from-design-assets to turn this structured context into a decision-ready Structured requirements from design assets UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Structured requirements from design assets UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/success-metrics-for-design-decisions/SKILL.md b/skills/success-metrics-for-design-decisions/SKILL.md deleted file mode 100644 index 6130b5d6..00000000 --- a/skills/success-metrics-for-design-decisions/SKILL.md +++ /dev/null @@ -1,234 +0,0 @@ ---- -name: success-metrics-for-design-decisions -description: >- - Success metrics for design decisions. Use when the user needs a product workflow for - business analysis related to success metrics for design decisions. Trigger terms: pm, - success-metrics, business-analysis, design. ---- - - - -# Success metrics for design decisions - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `success-metrics-for-design-decisions` -- **Lifecycle**: Design -- **Category**: Analytics -- **Primary artifact**: Success metrics for design decisions UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Success metrics for design decisions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_GOALS}} -- {{PRODUCT_CONTEXT}} -- {{USER_OUTCOMES}} - - -GOAL -Translate `DESIGN_GOALS`, `PRODUCT_CONTEXT`, and `USER_OUTCOMES` into a measurable success-metrics system for design decisions. -Success metric: -- Defines success from user, business, and product perspectives. -- Produces primary/secondary/guardrail/leading metrics with SMART definitions. -- Includes instrumentation, baseline/target logic, and decision-ready analysis plan. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required metric-design steps: - 1. Define success (user/business/product). - 2. Map metric types (behavior, outcome, business, quality, leading). - 3. Apply SMART criteria to each key metric. - 4. Define measurement approach (instrumentation, tools, sample/stat criteria). - 5. Set baselines and targets (minimum, target, stretch, timeframe). - 6. Add guardrails for unintended consequences. -- Keep metrics decision-oriented and linked to design goals (avoid vanity metrics). -- Explicitly note risks/limitations where metrics may not capture full reality. -- Label assumptions clearly when baseline/tooling/sample data is incomplete. - -FORMAT -Return exactly this structure: - - - -**User Success Means:** -[Describe what improves from user perspective - concrete outcomes] - -**Business Success Means:** -[Describe what improves from business perspective - concrete outcomes] - -**Product Success Means:** -[Describe what improves in the product - concrete outcomes] - - - - -**Metric Name:** [Clear, specific metric name] - -**What It Measures:** [Exactly what behavior or outcome] - -**Why It Matters:** [How it connects to goals] - -**Type:** [Behavior/Outcome/Business/Quality] - -**Measurement Method:** -- How: [Specific tracking approach] -- Where: [What system/tool] -- Frequency: [How often measured] -- Sample: [Who/what is included] - -**Current Baseline:** [If known, current performance] - -**Targets:** -- Minimum acceptable: [X%/number] -- Target: [Y%/number] -- Stretch: [Z%/number] -- Timeframe: [When to measure] - -**Statistical Criteria:** -- Sample size needed: [N users/sessions] -- Significance level: [e.g., 95% confidence] -- Minimum detectable effect: [smallest meaningful change] - -**Risks/Limitations:** -[What could make this metric misleading? What doesn't it capture?] - - - -[Repeat structure for 3-5 primary metrics] - - - - -[List 3-5 secondary metrics that provide additional context: -- Metric name: [Description, why it's useful] -- Metric name: [Description, why it's useful]] - - - -[Metrics to ensure you're not causing harm: -- Metric: [Description] -- Threshold: [What value would indicate a problem] -- Why: [What unintended consequence this guards against]] - - - -[Metrics that predict success before primary metrics show results: -- Indicator: [Description] -- Why it predicts success: [Connection to outcomes] -- When to measure: [Timeline]] - - - -**Implementation Requirements:** -- Events to track: [List specific events] -- Properties to capture: [Data points per event] -- Tools needed: [Analytics platform, A/B test framework, survey tool, etc.] -- Team dependencies: [Who needs to implement] -- Timeline: [When instrumentation will be ready] - -**Analysis Plan:** -- Segments to analyze: [User cohorts, use cases, etc.] -- Comparison approach: [A/B test, before/after, cohort comparison] -- Reporting cadence: [Daily/Weekly/Monthly] -- Decision timeline: [When to make go/no-go decision] - -**Baseline Collection:** -[If redesign, describe how to establish current state before changes] - - - -[How to make decisions when metrics conflict: -- If [Metric A] improves but [Metric B] declines, prioritize [A/B] because [rationale] -- Acceptable tradeoffs: [What you're willing to sacrifice for what gain] -- Unacceptable tradeoffs: [What must never decline]] - - - -[How to supplement quantitative metrics: -- User interviews: [What to ask] -- Usability testing: [What to observe] -- Support tickets: [What patterns to look for] -- Feedback surveys: [What questions to include]] - - - -[Describe what a single-page success dashboard should show: -- Key metric tiles -- Trend visualization -- Segment breakdowns -- Guardrail status -- Action triggers] - - - -FAILURE -- Any required schema section is missing or malformed. -- Metrics are not SMART or not clearly tied to design goals/outcomes. -- Baselines/targets/timeframes are missing for primary metrics. -- Guardrail or leading indicators are missing. -- Measurement plan lacks instrumentation detail or decision cadence. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/success-metrics-for-design-decisions/SKILL.md.tmpl b/skills/success-metrics-for-design-decisions/SKILL.md.tmpl deleted file mode 100644 index 127d9e73..00000000 --- a/skills/success-metrics-for-design-decisions/SKILL.md.tmpl +++ /dev/null @@ -1,175 +0,0 @@ ---- -name: success-metrics-for-design-decisions -description: >- - Success metrics for design decisions. Use when the user needs a product workflow for - business analysis related to success metrics for design decisions. Trigger terms: pm, - success-metrics, business-analysis, design. ---- -# Success metrics for design decisions - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Success metrics for design decisions**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{DESIGN_GOALS}} -- {{PRODUCT_CONTEXT}} -- {{USER_OUTCOMES}} - - -GOAL -Translate `DESIGN_GOALS`, `PRODUCT_CONTEXT`, and `USER_OUTCOMES` into a measurable success-metrics system for design decisions. -Success metric: -- Defines success from user, business, and product perspectives. -- Produces primary/secondary/guardrail/leading metrics with SMART definitions. -- Includes instrumentation, baseline/target logic, and decision-ready analysis plan. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required metric-design steps: - 1. Define success (user/business/product). - 2. Map metric types (behavior, outcome, business, quality, leading). - 3. Apply SMART criteria to each key metric. - 4. Define measurement approach (instrumentation, tools, sample/stat criteria). - 5. Set baselines and targets (minimum, target, stretch, timeframe). - 6. Add guardrails for unintended consequences. -- Keep metrics decision-oriented and linked to design goals (avoid vanity metrics). -- Explicitly note risks/limitations where metrics may not capture full reality. -- Label assumptions clearly when baseline/tooling/sample data is incomplete. - -FORMAT -Return exactly this structure: - - - -**User Success Means:** -[Describe what improves from user perspective - concrete outcomes] - -**Business Success Means:** -[Describe what improves from business perspective - concrete outcomes] - -**Product Success Means:** -[Describe what improves in the product - concrete outcomes] - - - - -**Metric Name:** [Clear, specific metric name] - -**What It Measures:** [Exactly what behavior or outcome] - -**Why It Matters:** [How it connects to goals] - -**Type:** [Behavior/Outcome/Business/Quality] - -**Measurement Method:** -- How: [Specific tracking approach] -- Where: [What system/tool] -- Frequency: [How often measured] -- Sample: [Who/what is included] - -**Current Baseline:** [If known, current performance] - -**Targets:** -- Minimum acceptable: [X%/number] -- Target: [Y%/number] -- Stretch: [Z%/number] -- Timeframe: [When to measure] - -**Statistical Criteria:** -- Sample size needed: [N users/sessions] -- Significance level: [e.g., 95% confidence] -- Minimum detectable effect: [smallest meaningful change] - -**Risks/Limitations:** -[What could make this metric misleading? What doesn't it capture?] - - - -[Repeat structure for 3-5 primary metrics] - - - - -[List 3-5 secondary metrics that provide additional context: -- Metric name: [Description, why it's useful] -- Metric name: [Description, why it's useful]] - - - -[Metrics to ensure you're not causing harm: -- Metric: [Description] -- Threshold: [What value would indicate a problem] -- Why: [What unintended consequence this guards against]] - - - -[Metrics that predict success before primary metrics show results: -- Indicator: [Description] -- Why it predicts success: [Connection to outcomes] -- When to measure: [Timeline]] - - - -**Implementation Requirements:** -- Events to track: [List specific events] -- Properties to capture: [Data points per event] -- Tools needed: [Analytics platform, A/B test framework, survey tool, etc.] -- Team dependencies: [Who needs to implement] -- Timeline: [When instrumentation will be ready] - -**Analysis Plan:** -- Segments to analyze: [User cohorts, use cases, etc.] -- Comparison approach: [A/B test, before/after, cohort comparison] -- Reporting cadence: [Daily/Weekly/Monthly] -- Decision timeline: [When to make go/no-go decision] - -**Baseline Collection:** -[If redesign, describe how to establish current state before changes] - - - -[How to make decisions when metrics conflict: -- If [Metric A] improves but [Metric B] declines, prioritize [A/B] because [rationale] -- Acceptable tradeoffs: [What you're willing to sacrifice for what gain] -- Unacceptable tradeoffs: [What must never decline]] - - - -[How to supplement quantitative metrics: -- User interviews: [What to ask] -- Usability testing: [What to observe] -- Support tickets: [What patterns to look for] -- Feedback surveys: [What questions to include]] - - - -[Describe what a single-page success dashboard should show: -- Key metric tiles -- Trend visualization -- Segment breakdowns -- Guardrail status -- Action triggers] - - - -FAILURE -- Any required schema section is missing or malformed. -- Metrics are not SMART or not clearly tied to design goals/outcomes. -- Baselines/targets/timeframes are missing for primary metrics. -- Guardrail or leading indicators are missing. -- Measurement plan lacks instrumentation detail or decision cadence. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/success-metrics-for-design-decisions/agents/openai.yaml b/skills/success-metrics-for-design-decisions/agents/openai.yaml deleted file mode 100644 index 42fd4c9e..00000000 --- a/skills/success-metrics-for-design-decisions/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Success metrics for design decisions" - short_description: "Success metrics for design decisions. Use when the user needs a product workflow for business analysis related to..." - brand_color: "#0F766E" - default_prompt: "Use $success-metrics-for-design-decisions with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/success-metrics-for-design-decisions/productize.json b/skills/success-metrics-for-design-decisions/productize.json deleted file mode 100644 index 70480e3c..00000000 --- a/skills/success-metrics-for-design-decisions/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Success metrics for design decisions", - "category": "Analytics", - "lifecycle": "Design", - "tags": [ - "success-metrics-for-design-decisions", - "success", - "metrics", - "design", - "decisions", - "business", - "analytics" - ], - "use_when": "Success metrics for design decisions. Use when the user needs a product workflow for business analysis related to success metrics for design decisions. Trigger terms: pm, success-metrics, business-analysis, design.", - "do_not_use_when": "Do not use Success metrics for design decisions when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Success metrics for design decisions UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "success-metrics-for-design-decisions", - "success", - "metrics", - "design", - "decisions", - "business", - "analytics" - ], - "framework_fit": "Success metrics for design decisions fits Analytics work in the Design lifecycle when the user needs Success metrics for design decisions UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Success metrics for design decisions UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Success metrics for design decisions as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Success metrics for design decisions when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $success-metrics-for-design-decisions to turn this success context into a decision-ready Success metrics for design decisions UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Success metrics for design decisions UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/support-tickets-as-actionable-product-improvements/SKILL.md b/skills/support-tickets-as-actionable-product-improvements/SKILL.md deleted file mode 100644 index 4bc028a2..00000000 --- a/skills/support-tickets-as-actionable-product-improvements/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: support-tickets-as-actionable-product-improvements -description: >- - Support tickets as actionable product improvements. Use when the user needs a product - workflow for business analysis related to support tickets as actionable product - improvements. Trigger terms: pm, business-analysis, support, product-improvements, feedback. ---- - - - -# Support tickets as actionable product improvements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `support-tickets-as-actionable-product-improvements` -- **Lifecycle**: Launch & Learn -- **Category**: Discovery -- **Primary artifact**: Support tickets as actionable product improvements launch learning report with release evidence, feedback, decision, and next iteration - -Use this skill to run the Productize prompt contract for **Support tickets as actionable product improvements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SUPPORT_TICKETS}} - - -GOAL -Convert `SUPPORT_TICKETS` into evidence-backed trends and a prioritized product-improvement backlog. -Success metric: -- Categorizes ticket themes with clear frequency/severity signals. -- Identifies major recurring patterns and notable critical issues. -- Produces prioritized improvements tied to explicit ticket evidence. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Categorize tickets/issues. - 2. Quantify category frequency. - 3. Identify recurring themes and severe/unusual issues. - 4. Detect pattern signals (cross-user, time-based, or correlated issues when available). - 5. Prioritize improvements by frequency, severity/impact, and estimated effort. -- Keep all claims grounded in provided support-ticket data. -- Label assumptions if timestamps, severity labels, or effort signals are missing. - -FORMAT -Return exactly this structure: - - -[3-5 major trends with evidence from support tickets, including category frequency and notable severe issues] - - - -List at least 5 prioritized improvements, ranked from highest to lowest priority. For each improvement: -1. [Improvement Name] - - Description: Brief description of the improvement - - Justification: Explain why this improvement is important, citing specific trends or issues from the data - - Priority Drivers: Frequency / Severity / Effort rationale - - Potential Impact: Describe the expected positive impact on user experience - - -FAILURE -- Missing `` or ``. -- Fewer than 5 prioritized improvements. -- Prioritization is not supported by frequency/severity/effort reasoning. -- Claims are generic or not grounded in provided ticket evidence. -- Assumptions are used but not explicitly stated. diff --git a/skills/support-tickets-as-actionable-product-improvements/SKILL.md.tmpl b/skills/support-tickets-as-actionable-product-improvements/SKILL.md.tmpl deleted file mode 100644 index ac9d3e5f..00000000 --- a/skills/support-tickets-as-actionable-product-improvements/SKILL.md.tmpl +++ /dev/null @@ -1,69 +0,0 @@ ---- -name: support-tickets-as-actionable-product-improvements -description: >- - Support tickets as actionable product improvements. Use when the user needs a product - workflow for business analysis related to support tickets as actionable product - improvements. Trigger terms: pm, business-analysis, support, product-improvements, feedback. ---- -# Support tickets as actionable product improvements - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Support tickets as actionable product improvements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{SUPPORT_TICKETS}} - - -GOAL -Convert `SUPPORT_TICKETS` into evidence-backed trends and a prioritized product-improvement backlog. -Success metric: -- Categorizes ticket themes with clear frequency/severity signals. -- Identifies major recurring patterns and notable critical issues. -- Produces prioritized improvements tied to explicit ticket evidence. -- Follows the required output schema exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps: - 1. Categorize tickets/issues. - 2. Quantify category frequency. - 3. Identify recurring themes and severe/unusual issues. - 4. Detect pattern signals (cross-user, time-based, or correlated issues when available). - 5. Prioritize improvements by frequency, severity/impact, and estimated effort. -- Keep all claims grounded in provided support-ticket data. -- Label assumptions if timestamps, severity labels, or effort signals are missing. - -FORMAT -Return exactly this structure: - - -[3-5 major trends with evidence from support tickets, including category frequency and notable severe issues] - - - -List at least 5 prioritized improvements, ranked from highest to lowest priority. For each improvement: -1. [Improvement Name] - - Description: Brief description of the improvement - - Justification: Explain why this improvement is important, citing specific trends or issues from the data - - Priority Drivers: Frequency / Severity / Effort rationale - - Potential Impact: Describe the expected positive impact on user experience - - -FAILURE -- Missing `` or ``. -- Fewer than 5 prioritized improvements. -- Prioritization is not supported by frequency/severity/effort reasoning. -- Claims are generic or not grounded in provided ticket evidence. -- Assumptions are used but not explicitly stated. diff --git a/skills/support-tickets-as-actionable-product-improvements/agents/openai.yaml b/skills/support-tickets-as-actionable-product-improvements/agents/openai.yaml deleted file mode 100644 index 98bffa3e..00000000 --- a/skills/support-tickets-as-actionable-product-improvements/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Support tickets as actionable product improvements" - short_description: "Support tickets as actionable product improvements. Use when the user needs a product workflow for business analysis..." - brand_color: "#0D9488" - default_prompt: "Use $support-tickets-as-actionable-product-improvements with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/support-tickets-as-actionable-product-improvements/productize.json b/skills/support-tickets-as-actionable-product-improvements/productize.json deleted file mode 100644 index 3c27020d..00000000 --- a/skills/support-tickets-as-actionable-product-improvements/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Support tickets as actionable product improvements", - "category": "Discovery", - "lifecycle": "Launch & Learn", - "tags": [ - "support-tickets-as-actionable-product-improvements", - "support", - "tickets", - "actionable", - "improvements", - "business", - "discovery" - ], - "use_when": "Support tickets as actionable product improvements. Use when the user needs a product workflow for business analysis related to support tickets as actionable product improvements. Trigger terms: pm, business-analysis, support, product-improvements, feedback.", - "do_not_use_when": "Do not use Support tickets as actionable product improvements when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Support tickets as actionable product improvements launch learning report with release evidence, feedback, decision, and next iteration", - "routing_signals": [ - "support-tickets-as-actionable-product-improvements", - "support", - "tickets", - "actionable", - "improvements", - "business", - "discovery" - ], - "framework_fit": "Appropriate when support tickets, customer complaints, or feedback queues need to become product themes, severity patterns, and prioritized improvements.", - "failure_modes": [ - "Produces Support tickets as actionable product improvements launch learning report with release evidence, feedback, decision, and next iteration without tying recommendations to the user's Launch & Learn stage, evidence, and decision pressure.", - "Treats Support tickets as actionable product improvements as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Support tickets as actionable product improvements when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $support-tickets-as-actionable-product-improvements to turn this support context into a decision-ready Support tickets as actionable product improvements launch learning report with release evidence, feedback, decision, and next iteration.", - "expected_artifact": "Support tickets as actionable product improvements launch learning report with release evidence, feedback, decision, and next iteration" - } - ] -} diff --git a/skills/sustainable-business-model/SKILL.md b/skills/sustainable-business-model/SKILL.md deleted file mode 100644 index cb1d64e8..00000000 --- a/skills/sustainable-business-model/SKILL.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -name: sustainable-business-model -description: >- - Design or redesign a business model for sustainability. Use when a company, - founder, innovation team, or strategist wants to create social/environmental value, - reduce social/environmental harm, move toward circularity, use sustainable business - model patterns, combine sustainability patterns, redesign revenue/access/financing, - or asks "make this business model sustainable", "what sustainable model patterns - fit", "how do we turn this sustainability challenge into opportunities", or - "design a sustainable business model". ---- - - - -# Sustainable Business Model - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `sustainable-business-model` -- **Lifecycle**: Strategize -- **Category**: Business Model -- **Primary artifact**: Sustainable Business Model business-model memo with value capture logic, risks, and next tests - -Create a business model concept that makes social, environmental, and economic value -logic explicit. - -## Argument Hint - -`` - -## Usage - -```text -/sustainable-business-model $ARGUMENTS -``` - -## Core Rule - -Do not bolt sustainability onto an unchanged model. Redesign how value is created, -delivered, captured, preserved, shared, or regenerated. - -Load `references/pattern-groups.md` when selecting sustainable business model -patterns. - -Load `references/output-format.md` when producing a formal concept, workshop -artifact, or handoff to `business-model-design`. - -## Workflow - -### 1. Frame the Sustainability Challenge - -Identify: - -- The current product/service, customer, user, payer, and operating model. -- Social or environmental harms, waste, exclusion, access barriers, or negative - externalities. -- Who bears the harm and who receives the value today. -- The business constraints: margin, channel, regulation, capabilities, assets, and - stakeholder expectations. - -### 2. Translate Challenge Into Opportunity Space - -Ask: - -- What would have to be true for this challenge to become a viable business - opportunity? -- Which actor could pay, contribute, reuse, repair, share, finance, distribute, or - benefit differently? -- Which current waste stream, underused asset, excluded group, or stakeholder - misalignment could become part of the model? - -### 3. Select Pattern Groups - -Choose 2-5 relevant pattern groups. Common groups include: - -- Pricing and revenue. -- Financing. -- Ecodesign. -- Closing the loop. -- Giving. -- Access provision. -- Social mission. - -Use pattern combinations rather than isolated tactics when the challenge is systemic. - -### 4. Build Model Options - -For each option, define: - -- Value created: economic, social, environmental. -- Value destroyed or risk shifted. -- Stakeholders and incentives. -- Revenue and financing logic. -- Key activities/resources/partners. -- Implementation obstacles and validation questions. - -### 5. Recommend a Direction - -Compare options on: - -- Sustainability impact. -- Business viability. -- Capability fit. -- Customer/stakeholder adoption. -- Implementation complexity. -- Evidence needed. - -Default output includes one recommended model and 1-2 alternates. - -## Output Rules - -- Be explicit about tradeoffs and rebound effects. -- Do not equate sustainability with branding, donations, or material substitution only. -- Make the business model mechanism clear: who does what differently, who pays, and - why it scales. -- Mark uncertain impact claims as assumptions. -- When the user needs a full operating canvas, hand off the selected model to - `business-model-design`. diff --git a/skills/sustainable-business-model/SKILL.md.tmpl b/skills/sustainable-business-model/SKILL.md.tmpl deleted file mode 100644 index 05f94430..00000000 --- a/skills/sustainable-business-model/SKILL.md.tmpl +++ /dev/null @@ -1,110 +0,0 @@ ---- -name: sustainable-business-model -description: >- - Design or redesign a business model for sustainability. Use when a company, - founder, innovation team, or strategist wants to create social/environmental value, - reduce social/environmental harm, move toward circularity, use sustainable business - model patterns, combine sustainability patterns, redesign revenue/access/financing, - or asks "make this business model sustainable", "what sustainable model patterns - fit", "how do we turn this sustainability challenge into opportunities", or - "design a sustainable business model". ---- -# Sustainable Business Model - -{{PRODUCTIZE_PREAMBLE}} - -Create a business model concept that makes social, environmental, and economic value -logic explicit. - -## Argument Hint - -`` - -## Usage - -```text -/sustainable-business-model $ARGUMENTS -``` - -## Core Rule - -Do not bolt sustainability onto an unchanged model. Redesign how value is created, -delivered, captured, preserved, shared, or regenerated. - -Load `references/pattern-groups.md` when selecting sustainable business model -patterns. - -Load `references/output-format.md` when producing a formal concept, workshop -artifact, or handoff to `business-model-design`. - -## Workflow - -### 1. Frame the Sustainability Challenge - -Identify: - -- The current product/service, customer, user, payer, and operating model. -- Social or environmental harms, waste, exclusion, access barriers, or negative - externalities. -- Who bears the harm and who receives the value today. -- The business constraints: margin, channel, regulation, capabilities, assets, and - stakeholder expectations. - -### 2. Translate Challenge Into Opportunity Space - -Ask: - -- What would have to be true for this challenge to become a viable business - opportunity? -- Which actor could pay, contribute, reuse, repair, share, finance, distribute, or - benefit differently? -- Which current waste stream, underused asset, excluded group, or stakeholder - misalignment could become part of the model? - -### 3. Select Pattern Groups - -Choose 2-5 relevant pattern groups. Common groups include: - -- Pricing and revenue. -- Financing. -- Ecodesign. -- Closing the loop. -- Giving. -- Access provision. -- Social mission. - -Use pattern combinations rather than isolated tactics when the challenge is systemic. - -### 4. Build Model Options - -For each option, define: - -- Value created: economic, social, environmental. -- Value destroyed or risk shifted. -- Stakeholders and incentives. -- Revenue and financing logic. -- Key activities/resources/partners. -- Implementation obstacles and validation questions. - -### 5. Recommend a Direction - -Compare options on: - -- Sustainability impact. -- Business viability. -- Capability fit. -- Customer/stakeholder adoption. -- Implementation complexity. -- Evidence needed. - -Default output includes one recommended model and 1-2 alternates. - -## Output Rules - -- Be explicit about tradeoffs and rebound effects. -- Do not equate sustainability with branding, donations, or material substitution only. -- Make the business model mechanism clear: who does what differently, who pays, and - why it scales. -- Mark uncertain impact claims as assumptions. -- When the user needs a full operating canvas, hand off the selected model to - `business-model-design`. diff --git a/skills/sustainable-business-model/agents/openai.yaml b/skills/sustainable-business-model/agents/openai.yaml deleted file mode 100644 index 06b5edb8..00000000 --- a/skills/sustainable-business-model/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Sustainable Business Model" - short_description: "Design or redesign a business model for sustainability. Use when a company, founder, innovation team, or strategist..." - brand_color: "#9333EA" - default_prompt: "Use $sustainable-business-model with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/sustainable-business-model/productize.json b/skills/sustainable-business-model/productize.json deleted file mode 100644 index 09725f75..00000000 --- a/skills/sustainable-business-model/productize.json +++ /dev/null @@ -1,49 +0,0 @@ -{ - "title": "Sustainable Business Model", - "category": "Business Model", - "tags": [ - "sustainability", - "business-model", - "circular-economy", - "social-impact", - "ecodesign", - "access", - "sustainable-innovation", - "sustainable-business-model", - "sustainable", - "business", - "model", - "innovation", - "design", - "redesign" - ], - "lifecycle": "Strategize", - "use_when": "Design or redesign a business model for sustainability. Use when a company, founder, innovation team, or strategist wants to create social/environmental value, reduce social/environmental harm, move toward circularity, use sustainable business model patterns, combine sustainability patterns, redesign revenue/access/financing, or asks \"make this business model sustainable\", \"what sustainable model patterns fit\", \"how do we turn this sustainability challenge into opportunities\", or \"design a sustainable business model\".", - "do_not_use_when": "Do not use Sustainable Business Model when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Sustainable Business Model business-model memo with value capture logic, risks, and next tests", - "routing_signals": [ - "sustainable-business-model", - "sustainable", - "business", - "model", - "innovation", - "design", - "redesign" - ], - "framework_fit": "Sustainable Business Model fits Business Model work in the Strategize lifecycle when the user needs Sustainable Business Model business-model memo with value capture logic, risks, and next tests and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Sustainable Business Model business-model memo with value capture logic, risks, and next tests without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Sustainable Business Model as generic Business Model advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Sustainable Business Model when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $sustainable-business-model to turn this sustainable context into a decision-ready Sustainable Business Model business-model memo with value capture logic, risks, and next tests.", - "expected_artifact": "Sustainable Business Model business-model memo with value capture logic, risks, and next tests" - } - ], - "references": [ - "references/output-format.md", - "references/pattern-groups.md" - ] -} diff --git a/skills/sustainable-business-model/references/output-format.md b/skills/sustainable-business-model/references/output-format.md deleted file mode 100644 index ee7a2fec..00000000 --- a/skills/sustainable-business-model/references/output-format.md +++ /dev/null @@ -1,56 +0,0 @@ -# Sustainable Business Model Output - -```markdown -## Sustainable Business Model: [Name] - -### Challenge Frame -| Dimension | Current Situation | Sustainability Issue | Opportunity | -|---|---|---|---| -| Customer / user | | | | -| Product / service | | | | -| Operations | | | | -| Revenue / cost | | | | -| Stakeholders | | | | - -### Pattern Shortlist -| Pattern Group | Why It Fits | What Would Have To Be True | -|---|---|---| - -### Model Options -| Option | Mechanism | Social Value | Environmental Value | Economic Logic | Main Risk | -|---|---|---|---|---|---| - -### Recommended Model -[Name and explain the recommended business model.] - -### Business Model Mechanism -| Element | Design | -|---|---| -| Target stakeholder/customer | | -| Value proposition | | -| Key activities/resources | | -| Partners | | -| Revenue/financing | | -| Cost drivers | | -| Sustainability mechanism | | - -### Tradeoffs and Risks -| Risk | Why It Matters | Mitigation / Test | -|---|---|---| - -### Validation Plan -1. [Assumption] -> [test] -> [decision threshold] -2. [Assumption] -> [test] -> [decision threshold] -3. [Assumption] -> [test] -> [decision threshold] -``` - -## Scoring Guide - -Use Low / Medium / High for first-pass comparison: - -- Sustainability impact. -- Business viability. -- Capability fit. -- Stakeholder adoption. -- Implementation complexity. -- Evidence confidence. diff --git a/skills/sustainable-business-model/references/pattern-groups.md b/skills/sustainable-business-model/references/pattern-groups.md deleted file mode 100644 index 03bea877..00000000 --- a/skills/sustainable-business-model/references/pattern-groups.md +++ /dev/null @@ -1,30 +0,0 @@ -# Sustainable Business Model Pattern Groups - -Use pattern groups as design lenses. Combine groups when one pattern cannot solve the -whole challenge. - -| Pattern Group | Use When | Mechanism To Explore | -|---|---|---| -| Pricing and revenue | The sustainable option needs a different way to monetize value. | Pay-per-use, subscriptions, outcome-based pricing, premium for verified impact, shared savings, deposits, resale, service revenue. | -| Financing | Upfront cost, asset intensity, or stakeholder investment blocks adoption. | Leasing, pay-as-you-go, third-party financing, cooperative ownership, blended finance, advance market commitments. | -| Ecodesign | Environmental harm is embedded in product design, materials, packaging, or use phase. | Reduce material/energy intensity, modularity, durability, repairability, upgradability, low-impact materials. | -| Closing the loop | Value is lost after use or waste streams are material. | Reuse, repair, refurbish, remanufacture, resale, take-back, recycling, industrial symbiosis. | -| Giving | The model intentionally transfers value to underserved groups or causes. | Buy-one-give-one, donation mechanisms, cross-subsidy, free access for selected groups. | -| Access provision | People are excluded by price, geography, capability, information, or ownership barriers. | Shared access, low-cost versions, local distribution, inclusive finance, training, community-based delivery. | -| Social mission | The business model uses disadvantaged or mission-aligned stakeholders as productive partners. | Employment, supplier inclusion, community production, cooperative participation, capability building. | - -## Pattern Combination Prompts - -- Can ecodesign reduce lifecycle cost enough to support access provision? -- Can closing-the-loop create a new revenue stream? -- Can financing reduce adoption friction for a sustainable product? -- Can social mission partners become part of delivery, repair, collection, or support? -- Can pricing reward lower impact behavior rather than only product ownership? - -## Evaluation Prompts - -- What problem does this pattern group solve in this case? -- Which stakeholder must change behavior? -- What incentive makes that behavior rational? -- What evidence would prove the pattern can work? -- What new risk or negative externality could the pattern create? diff --git a/skills/synthesize-research/SKILL.md b/skills/synthesize-research/SKILL.md deleted file mode 100644 index 86403290..00000000 --- a/skills/synthesize-research/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: synthesize-research -description: >- - Synthesize user research from interviews, surveys, and feedback into structured insights. Use - when making sense of notes, survey responses, support tickets, themes, frequency, impact, or - roadmap recommendations. ---- - - - -# Synthesize Research - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `synthesize-research` -- **Lifecycle**: Discover -- **Category**: Discovery -- **Primary artifact**: Synthesize Research research brief with evidence, insight clusters, assumptions, and next validation steps - -Synthesize user research from multiple sources into structured insights and recommendations. - -## Argument Hint - -`` - -## Usage - -```text -/synthesize-research $ARGUMENTS -``` - -## Workflow - -### 1. Gather Inputs - -Accept pasted notes, uploaded files, transcripts, survey results, support tickets, sales notes, analytics, or connected knowledge-base content. - -Ask only what is needed: -- Research type and number of sources. -- Research question or hypothesis. -- Participant segments. -- Decision this research should inform. - -### 2. Extract Evidence - -For each source, extract: -- Observations. -- Direct quotes with source attribution. -- Behaviors versus stated preferences. -- Pain points, workarounds, unmet needs. -- Positive signals. -- Segment and context. - -### 3. Identify Themes - -Apply thematic analysis: -1. Read all data before coding. -2. Tag observations generously. -3. Cluster related codes. -4. Refine themes until they are distinct and evidence-backed. -5. Rank by frequency, impact, and confidence. - -Use a priority matrix: -- High frequency + high impact: top priority. -- Low frequency + high impact: important for specific segments. -- High frequency + low impact: quality-of-life. -- Low frequency + low impact: note and deprioritize. - -### 4. Generate Synthesis - -Return: -- Research overview: methods, sources, questions, timeframe. -- Key findings: 5-8 prioritized findings with evidence, frequency, impact, and confidence. -- Segments or personas if patterns differ by group. -- Opportunity areas. -- Recommendations tied to findings. -- Open questions and suggested follow-up research. - -### 5. Quality Rules - -- Distinguish what users say from what users do. -- Treat contradictions as signal. -- Do not overstate findings from small samples. -- Use quotes as evidence, not as findings by themselves. -- Recommendations must be specific enough to act on. diff --git a/skills/synthesize-research/SKILL.md.tmpl b/skills/synthesize-research/SKILL.md.tmpl deleted file mode 100644 index d7cf5369..00000000 --- a/skills/synthesize-research/SKILL.md.tmpl +++ /dev/null @@ -1,77 +0,0 @@ ---- -name: synthesize-research -description: >- - Synthesize user research from interviews, surveys, and feedback into structured insights. Use - when making sense of notes, survey responses, support tickets, themes, frequency, impact, or - roadmap recommendations. ---- -# Synthesize Research - -{{PRODUCTIZE_PREAMBLE}} - -Synthesize user research from multiple sources into structured insights and recommendations. - -## Argument Hint - -`` - -## Usage - -```text -/synthesize-research $ARGUMENTS -``` - -## Workflow - -### 1. Gather Inputs - -Accept pasted notes, uploaded files, transcripts, survey results, support tickets, sales notes, analytics, or connected knowledge-base content. - -Ask only what is needed: -- Research type and number of sources. -- Research question or hypothesis. -- Participant segments. -- Decision this research should inform. - -### 2. Extract Evidence - -For each source, extract: -- Observations. -- Direct quotes with source attribution. -- Behaviors versus stated preferences. -- Pain points, workarounds, unmet needs. -- Positive signals. -- Segment and context. - -### 3. Identify Themes - -Apply thematic analysis: -1. Read all data before coding. -2. Tag observations generously. -3. Cluster related codes. -4. Refine themes until they are distinct and evidence-backed. -5. Rank by frequency, impact, and confidence. - -Use a priority matrix: -- High frequency + high impact: top priority. -- Low frequency + high impact: important for specific segments. -- High frequency + low impact: quality-of-life. -- Low frequency + low impact: note and deprioritize. - -### 4. Generate Synthesis - -Return: -- Research overview: methods, sources, questions, timeframe. -- Key findings: 5-8 prioritized findings with evidence, frequency, impact, and confidence. -- Segments or personas if patterns differ by group. -- Opportunity areas. -- Recommendations tied to findings. -- Open questions and suggested follow-up research. - -### 5. Quality Rules - -- Distinguish what users say from what users do. -- Treat contradictions as signal. -- Do not overstate findings from small samples. -- Use quotes as evidence, not as findings by themselves. -- Recommendations must be specific enough to act on. diff --git a/skills/synthesize-research/agents/openai.yaml b/skills/synthesize-research/agents/openai.yaml deleted file mode 100644 index d53a068d..00000000 --- a/skills/synthesize-research/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Synthesize Research" - short_description: "Synthesize user research from interviews, surveys, and feedback into structured insights. Use when making sense of..." - brand_color: "#0D9488" - default_prompt: "Use $synthesize-research with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/synthesize-research/productize.json b/skills/synthesize-research/productize.json deleted file mode 100644 index f0493fe5..00000000 --- a/skills/synthesize-research/productize.json +++ /dev/null @@ -1,43 +0,0 @@ -{ - "title": "Synthesize Research", - "category": "Discovery", - "tags": [ - "research-synthesis", - "interviews", - "survey", - "themes", - "insights", - "recommendations", - "synthesize-research", - "synthesize", - "research", - "surveys", - "feedback", - "discovery" - ], - "lifecycle": "Discover", - "use_when": "Synthesize user research from interviews, surveys, and feedback into structured insights. Use when making sense of notes, survey responses, support tickets, themes, frequency, impact, or roadmap recommendations.", - "do_not_use_when": "Do not use Synthesize Research when the request is mainly delivery planning, analytics readout, or stakeholder communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Synthesize Research research brief with evidence, insight clusters, assumptions, and next validation steps", - "routing_signals": [ - "synthesize-research", - "synthesize", - "research", - "interviews", - "surveys", - "feedback", - "discovery" - ], - "framework_fit": "Synthesize Research fits Discovery work in the Discover lifecycle when the user needs Synthesize Research research brief with evidence, insight clusters, assumptions, and next validation steps and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Synthesize Research research brief with evidence, insight clusters, assumptions, and next validation steps without tying recommendations to the user's Discover stage, evidence, and decision pressure.", - "Treats Synthesize Research as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Synthesize Research when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $synthesize-research to turn this synthesize context into a decision-ready Synthesize Research research brief with evidence, insight clusters, assumptions, and next validation steps.", - "expected_artifact": "Synthesize Research research brief with evidence, insight clusters, assumptions, and next validation steps" - } - ] -} diff --git a/skills/systematic-debugging/SKILL.md b/skills/systematic-debugging/SKILL.md deleted file mode 100644 index 19a5b6d6..00000000 --- a/skills/systematic-debugging/SKILL.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -name: systematic-debugging -description: >- - Four-phase debugging process: root cause first, then fix. Use when encountering bugs, - test failures, or unexpected behavior. ---- - - - -# Systematic Debugging - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `systematic-debugging` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Systematic Debugging AI-builder handoff with implementation scope, verification plan, and risks - -Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. - -## The Iron Law - -``` -NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST -``` - -If you haven't completed Phase 1, you cannot propose fixes. - -## The Four Phases - -### Phase 1: Root Cause Investigation - -**BEFORE attempting ANY fix:** - -1. **Read Error Messages Carefully** - - Don't skip past errors or warnings - - Read stack traces completely - - Note line numbers, file paths, error codes - -2. **Reproduce Consistently** - - Can you trigger it reliably? - - What are the exact steps? - - If not reproducible, gather more data - -3. **Check Recent Changes** - - Git diff, recent commits - - New dependencies, config changes - - Environmental differences - -4. **Trace Data Flow** - - Where does bad value originate? - - What called this with bad value? - - Keep tracing up until you find the source - -### Phase 2: Pattern Analysis - -1. **Find Working Examples** - - Locate similar working code in same codebase - -2. **Compare Against References** - - Read reference implementation completely - - Don't skim - read every line - -3. **Identify Differences** - - What's different between working and broken? - - List every difference, however small - -### Phase 3: Hypothesis and Testing - -1. **Form Single Hypothesis** - - State clearly: "I think X is the root cause because Y" - - Write it down - -2. **Test Minimally** - - Make the SMALLEST possible change - - One variable at a time - -3. **Verify Before Continuing** - - Did it work? Yes -> Phase 4 - - Didn't work? Form NEW hypothesis - - DON'T add more fixes on top - -### Phase 4: Implementation - -1. **Create Failing Test Case** - - Use the `tdd.md` skill - -2. **Implement Single Fix** - - ONE change at a time - - No "while I'm here" improvements - -3. **Verify Fix** - - Test passes now? - - No other tests broken? - -4. **If 3+ Fixes Failed: Question Architecture** - - Is this pattern fundamentally sound? - - Should we refactor vs continue fixing symptoms? - - Discuss before attempting more fixes - -## Red Flags - STOP and Follow Process - -- "Quick fix for now, investigate later" -- "Just try changing X and see if it works" -- "I don't fully understand but this might work" -- Proposing solutions before tracing data flow -- "One more fix attempt" (when already tried 2+) - -**ALL mean: STOP. Return to Phase 1.** - -## Quick Reference - -| Phase | Key Activities | Success Criteria | -|-------|---------------|------------------| -| 1. Root Cause | Read errors, reproduce, check changes | Understand WHAT and WHY | -| 2. Pattern | Find working examples, compare | Identify differences | -| 3. Hypothesis | Form theory, test minimally | Confirmed or new hypothesis | -| 4. Implementation | Create test, fix, verify | Bug resolved, tests pass | - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/systematic-debugging/SKILL.md.tmpl b/skills/systematic-debugging/SKILL.md.tmpl deleted file mode 100644 index 010baf0c..00000000 --- a/skills/systematic-debugging/SKILL.md.tmpl +++ /dev/null @@ -1,118 +0,0 @@ ---- -name: systematic-debugging -description: >- - Four-phase debugging process: root cause first, then fix. Use when encountering bugs, - test failures, or unexpected behavior. ---- -# Systematic Debugging - -{{PRODUCTIZE_PREAMBLE}} - -Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. - -## The Iron Law - -``` -NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST -``` - -If you haven't completed Phase 1, you cannot propose fixes. - -## The Four Phases - -### Phase 1: Root Cause Investigation - -**BEFORE attempting ANY fix:** - -1. **Read Error Messages Carefully** - - Don't skip past errors or warnings - - Read stack traces completely - - Note line numbers, file paths, error codes - -2. **Reproduce Consistently** - - Can you trigger it reliably? - - What are the exact steps? - - If not reproducible, gather more data - -3. **Check Recent Changes** - - Git diff, recent commits - - New dependencies, config changes - - Environmental differences - -4. **Trace Data Flow** - - Where does bad value originate? - - What called this with bad value? - - Keep tracing up until you find the source - -### Phase 2: Pattern Analysis - -1. **Find Working Examples** - - Locate similar working code in same codebase - -2. **Compare Against References** - - Read reference implementation completely - - Don't skim - read every line - -3. **Identify Differences** - - What's different between working and broken? - - List every difference, however small - -### Phase 3: Hypothesis and Testing - -1. **Form Single Hypothesis** - - State clearly: "I think X is the root cause because Y" - - Write it down - -2. **Test Minimally** - - Make the SMALLEST possible change - - One variable at a time - -3. **Verify Before Continuing** - - Did it work? Yes -> Phase 4 - - Didn't work? Form NEW hypothesis - - DON'T add more fixes on top - -### Phase 4: Implementation - -1. **Create Failing Test Case** - - Use the `tdd.md` skill - -2. **Implement Single Fix** - - ONE change at a time - - No "while I'm here" improvements - -3. **Verify Fix** - - Test passes now? - - No other tests broken? - -4. **If 3+ Fixes Failed: Question Architecture** - - Is this pattern fundamentally sound? - - Should we refactor vs continue fixing symptoms? - - Discuss before attempting more fixes - -## Red Flags - STOP and Follow Process - -- "Quick fix for now, investigate later" -- "Just try changing X and see if it works" -- "I don't fully understand but this might work" -- Proposing solutions before tracing data flow -- "One more fix attempt" (when already tried 2+) - -**ALL mean: STOP. Return to Phase 1.** - -## Quick Reference - -| Phase | Key Activities | Success Criteria | -|-------|---------------|------------------| -| 1. Root Cause | Read errors, reproduce, check changes | Understand WHAT and WHY | -| 2. Pattern | Find working examples, compare | Identify differences | -| 3. Hypothesis | Form theory, test minimally | Confirmed or new hypothesis | -| 4. Implementation | Create test, fix, verify | Bug resolved, tests pass | - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/systematic-debugging/agents/openai.yaml b/skills/systematic-debugging/agents/openai.yaml deleted file mode 100644 index d0c6d1b8..00000000 --- a/skills/systematic-debugging/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Systematic Debugging" - short_description: "Four-phase debugging process: root cause first, then fix. Use when encountering bugs, test failures, or unexpected..." - brand_color: "#334155" - default_prompt: "Use $systematic-debugging with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/systematic-debugging/productize.json b/skills/systematic-debugging/productize.json deleted file mode 100644 index e245d53b..00000000 --- a/skills/systematic-debugging/productize.json +++ /dev/null @@ -1,47 +0,0 @@ -{ - "title": "Systematic Debugging", - "category": "AI Execution", - "tags": [ - "debugging", - "root-cause-analysis", - "test-failures", - "engineering-discipline", - "hypothesis-testing", - "verification", - "systematic-debugging", - "systematic", - "technical", - "four", - "phase", - "process", - "root", - "execution" - ], - "lifecycle": "Build With AI", - "use_when": "Four-phase debugging process: root cause first, then fix. Use when encountering bugs, test failures, or unexpected behavior.", - "do_not_use_when": "Do not use Systematic Debugging when the request is mainly market strategy, research synthesis, finance modeling, or executive communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Systematic Debugging AI-builder handoff with implementation scope, verification plan, and risks", - "routing_signals": [ - "systematic-debugging", - "systematic", - "debugging", - "technical", - "four", - "phase", - "process", - "root", - "execution" - ], - "framework_fit": "Systematic Debugging fits AI Execution work in the Build With AI lifecycle when the user needs Systematic Debugging AI-builder handoff with implementation scope, verification plan, and risks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Systematic Debugging AI-builder handoff with implementation scope, verification plan, and risks without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats Systematic Debugging as generic AI Execution advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Systematic Debugging when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $systematic-debugging to turn this systematic context into a decision-ready Systematic Debugging AI-builder handoff with implementation scope, verification plan, and risks.", - "expected_artifact": "Systematic Debugging AI-builder handoff with implementation scope, verification plan, and risks" - } - ] -} diff --git a/skills/target-opportunity-selection-from-ost/SKILL.md b/skills/target-opportunity-selection-from-ost/SKILL.md deleted file mode 100644 index ccea63cd..00000000 --- a/skills/target-opportunity-selection-from-ost/SKILL.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -name: target-opportunity-selection-from-ost -description: >- - Target opportunity selection from OST. Use when the user needs a product workflow for - decision making related to target opportunity selection from ost. Trigger terms: pm, - decision-making, discovery, opportunity-solution-tree, prioritization. ---- - - - -# Target opportunity selection from OST - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `target-opportunity-selection-from-ost` -- **Lifecycle**: Think -- **Category**: Discovery -- **Primary artifact**: Target opportunity selection from OST product artifact with evidence, risks, recommendation, and next action - -Use this skill to run the Productize prompt contract for **Target opportunity selection from OST**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{BUSINESS_OUTCOME}} -- {{JOURNEY_NODES_AS_LIST}} -- {{INTERVIEW_TRANSCRIPTS_OR_STORY_SNIPPETS}} -- {{CONSTRAINTS_OR_PRINCIPLES}} -- {{OST_JSON}} -- Optional: {{WEIGHTS_JSON}} - - -GOAL -Produce a high-quality deliverable for: "Target opportunity selection from OST". -Success metric: -- Recommends exactly one small, distinct, moment-scoped target opportunity from the OST. -- Uses evidence-grounded scoring across Opportunity, Market, Company, and Customer factors. -- Produces a shortlist and recommendation that are traceable to OST/interview evidence. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if a required field is missing, state assumptions explicitly. -- Candidate harvesting: - - From `{{OST_JSON}}`, include leaf opportunities plus intermediate parents with 2+ specific children or explicit traceability evidence. - - Merge duplicates and reframe solution-framed items as opportunity/need statements. -- Score each candidate 1-5 on: - - Opportunity Sizing (OS), Market Factors (MF), Company Factors (CF), Customer Factors (CuF). -- Compute WPS with default weights unless `{{WEIGHTS_JSON}}` is provided and sums to 1.0: - - Default weights: OS 0.35, MF 0.20, CF 0.25, CuF 0.20. -- If factor data is missing, assign score `3` and flag as low evidence. -- Shortlist top 3-5 by WPS, then apply tie-breakers in order: - - distinctness (thinner slice), evidence quality, time-to-learning, risk diversification across moments. -- Recommend exactly one target opportunity that is small, distinct, moment-scoped, and independently addressable. -- Do not include solution effort or engineering feasibility estimates at this stage. -- Maintain traceability to interview/OST evidence and avoid exposing PII not present in inputs. - -FORMAT -Return exactly this structure: - -Part A - Candidate Inventory (from OST) -| id | moment | opportunity | level (leaf/parent) | distinct_from | evidence_summary | notes | -| -- | ------ | ----------- | ------------------- | ------------- | ---------------- | ----- | -[`evidence_summary` must include: `{frequency_count, confidence, #quotes}` with 1-2 short quote snippets.] - -Part B - Scoring Matrix -| id | OS (weight) | MF (weight) | CF (weight) | CuF (weight) | WPS | factor_rationales | -| -- | ----------: | ----------: | ----------: | -----------: | --: | ----------------- | -[Use 1-5 integers for factor scores and show WPS calculation basis.] - -Part C - Shortlist (Top 3-5) -- [id] - [1-2 sentence justification] -- [id] - [1-2 sentence justification] -- [id] - [1-2 sentence justification] -[Optional 4th/5th item] - -Part D - Recommendation (One Target Opportunity) -- Selected id & title: [id] - [opportunity] -- Why now: - - [3-5 evidence-grounded bullets] -- Scope check: - - [Confirm small distinct slice tied to one moment and independent from siblings] -- Risks/Unknowns: - - [Bullets] -- Immediate next steps: - - Generate 3 competing solution ideas for this opportunity. - - Draft assumption map (desirability, usability, feasibility, viability, ethical). - - Design smallest tests for riskiest assumptions with success criteria. - -Part E - Audit (Torres Alignment) -- No-effort policy honored? [yes/no + explanation] -- Moment distinctness verified? [yes/no + overlaps if any] -- Evidence gaps requiring quick follow-up interview or data pull: [Bullets] - -FAILURE -- Any required part/table/list item from `FORMAT` is missing or materially incomplete. -- Fewer than 3 or more than 5 shortlisted opportunities. -- Recommendation is not exactly one opportunity. -- Scoring is missing factor scores, WPS, or weight usage. -- Tie-break logic is not applied when close/top candidates conflict. -- Output includes effort/engineering-feasibility prioritization. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/target-opportunity-selection-from-ost/SKILL.md.tmpl b/skills/target-opportunity-selection-from-ost/SKILL.md.tmpl deleted file mode 100644 index 8dba5301..00000000 --- a/skills/target-opportunity-selection-from-ost/SKILL.md.tmpl +++ /dev/null @@ -1,103 +0,0 @@ ---- -name: target-opportunity-selection-from-ost -description: >- - Target opportunity selection from OST. Use when the user needs a product workflow for - decision making related to target opportunity selection from ost. Trigger terms: pm, - decision-making, discovery, opportunity-solution-tree, prioritization. ---- -# Target opportunity selection from OST - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Target opportunity selection from OST**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{BUSINESS_OUTCOME}} -- {{JOURNEY_NODES_AS_LIST}} -- {{INTERVIEW_TRANSCRIPTS_OR_STORY_SNIPPETS}} -- {{CONSTRAINTS_OR_PRINCIPLES}} -- {{OST_JSON}} -- Optional: {{WEIGHTS_JSON}} - - -GOAL -Produce a high-quality deliverable for: "Target opportunity selection from OST". -Success metric: -- Recommends exactly one small, distinct, moment-scoped target opportunity from the OST. -- Uses evidence-grounded scoring across Opportunity, Market, Company, and Customer factors. -- Produces a shortlist and recommendation that are traceable to OST/interview evidence. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if a required field is missing, state assumptions explicitly. -- Candidate harvesting: - - From `{{OST_JSON}}`, include leaf opportunities plus intermediate parents with 2+ specific children or explicit traceability evidence. - - Merge duplicates and reframe solution-framed items as opportunity/need statements. -- Score each candidate 1-5 on: - - Opportunity Sizing (OS), Market Factors (MF), Company Factors (CF), Customer Factors (CuF). -- Compute WPS with default weights unless `{{WEIGHTS_JSON}}` is provided and sums to 1.0: - - Default weights: OS 0.35, MF 0.20, CF 0.25, CuF 0.20. -- If factor data is missing, assign score `3` and flag as low evidence. -- Shortlist top 3-5 by WPS, then apply tie-breakers in order: - - distinctness (thinner slice), evidence quality, time-to-learning, risk diversification across moments. -- Recommend exactly one target opportunity that is small, distinct, moment-scoped, and independently addressable. -- Do not include solution effort or engineering feasibility estimates at this stage. -- Maintain traceability to interview/OST evidence and avoid exposing PII not present in inputs. - -FORMAT -Return exactly this structure: - -Part A - Candidate Inventory (from OST) -| id | moment | opportunity | level (leaf/parent) | distinct_from | evidence_summary | notes | -| -- | ------ | ----------- | ------------------- | ------------- | ---------------- | ----- | -[`evidence_summary` must include: `{frequency_count, confidence, #quotes}` with 1-2 short quote snippets.] - -Part B - Scoring Matrix -| id | OS (weight) | MF (weight) | CF (weight) | CuF (weight) | WPS | factor_rationales | -| -- | ----------: | ----------: | ----------: | -----------: | --: | ----------------- | -[Use 1-5 integers for factor scores and show WPS calculation basis.] - -Part C - Shortlist (Top 3-5) -- [id] - [1-2 sentence justification] -- [id] - [1-2 sentence justification] -- [id] - [1-2 sentence justification] -[Optional 4th/5th item] - -Part D - Recommendation (One Target Opportunity) -- Selected id & title: [id] - [opportunity] -- Why now: - - [3-5 evidence-grounded bullets] -- Scope check: - - [Confirm small distinct slice tied to one moment and independent from siblings] -- Risks/Unknowns: - - [Bullets] -- Immediate next steps: - - Generate 3 competing solution ideas for this opportunity. - - Draft assumption map (desirability, usability, feasibility, viability, ethical). - - Design smallest tests for riskiest assumptions with success criteria. - -Part E - Audit (Torres Alignment) -- No-effort policy honored? [yes/no + explanation] -- Moment distinctness verified? [yes/no + overlaps if any] -- Evidence gaps requiring quick follow-up interview or data pull: [Bullets] - -FAILURE -- Any required part/table/list item from `FORMAT` is missing or materially incomplete. -- Fewer than 3 or more than 5 shortlisted opportunities. -- Recommendation is not exactly one opportunity. -- Scoring is missing factor scores, WPS, or weight usage. -- Tie-break logic is not applied when close/top candidates conflict. -- Output includes effort/engineering-feasibility prioritization. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/target-opportunity-selection-from-ost/agents/openai.yaml b/skills/target-opportunity-selection-from-ost/agents/openai.yaml deleted file mode 100644 index 30036601..00000000 --- a/skills/target-opportunity-selection-from-ost/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Target opportunity selection from OST" - short_description: "Target opportunity selection from OST. Use when the user needs a product workflow for decision making related to..." - brand_color: "#0D9488" - default_prompt: "Use $target-opportunity-selection-from-ost with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/target-opportunity-selection-from-ost/productize.json b/skills/target-opportunity-selection-from-ost/productize.json deleted file mode 100644 index 7520a10b..00000000 --- a/skills/target-opportunity-selection-from-ost/productize.json +++ /dev/null @@ -1,40 +0,0 @@ -{ - "title": "Target opportunity selection from OST", - "category": "Discovery", - "lifecycle": "Think", - "tags": [ - "target-opportunity-selection-from-ost", - "target", - "opportunity", - "selection", - "ost", - "decision", - "making", - "discovery" - ], - "use_when": "Target opportunity selection from OST. Use when the user needs a product workflow for decision making related to target opportunity selection from ost. Trigger terms: pm, decision-making, discovery, opportunity-solution-tree, prioritization.", - "do_not_use_when": "Do not use Target opportunity selection from OST when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Target opportunity selection from OST product artifact with evidence, risks, recommendation, and next action", - "routing_signals": [ - "target-opportunity-selection-from-ost", - "target", - "opportunity", - "selection", - "ost", - "decision", - "making", - "discovery" - ], - "framework_fit": "Target opportunity selection from OST fits Discovery work in the Think lifecycle when the user needs Target opportunity selection from OST product artifact with evidence, risks, recommendation, and next action and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Target opportunity selection from OST product artifact with evidence, risks, recommendation, and next action without tying recommendations to the user's Think stage, evidence, and decision pressure.", - "Treats Target opportunity selection from OST as generic Discovery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Target opportunity selection from OST when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $target-opportunity-selection-from-ost to turn this target context into a decision-ready Target opportunity selection from OST product artifact with evidence, risks, recommendation, and next action.", - "expected_artifact": "Target opportunity selection from OST product artifact with evidence, risks, recommendation, and next action" - } - ] -} diff --git a/skills/task-list-optimization-and-contingency-based-project-planning/SKILL.md b/skills/task-list-optimization-and-contingency-based-project-planning/SKILL.md deleted file mode 100644 index 5e92c003..00000000 --- a/skills/task-list-optimization-and-contingency-based-project-planning/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: task-list-optimization-and-contingency-based-project-planning -description: >- - Task list optimization and contingency-based project planning. Use when the user needs a - product workflow for project management related to task list optimization and - contingency-based project planning. Trigger terms: project-management, planning, scheduling, - risk-management. ---- - - - -# Task list optimization and contingency-based project planning - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `task-list-optimization-and-contingency-based-project-planning` -- **Lifecycle**: Plan -- **Category**: Operations -- **Primary artifact**: Task list optimization and contingency-based project planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Use this skill to run the Productize prompt contract for **Task list optimization and contingency-based project planning**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TASK_LIST}} - - -GOAL -Produce a high-quality deliverable for: Task list optimization and contingency-based project planning. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze and optimize `{{TASK_LIST}}` by identifying dependencies, gaps, and ambiguities. -- Add missing tasks needed for completion and clarify ambiguous items. -- Sequence tasks for efficiency, highlight critical path, and assign rough durations. -- Identify resource constraints and opportunities for parallel execution. -- Build contingency plans with blockers, workarounds, and buffers. -- Define decision milestones with go/no-go criteria and metrics. -- Include a brief explanation of sequencing and key decisions. - -FORMAT -Return exactly this structure: - - - - [Sequenced tasks including dependencies, rough durations, critical path markers, and any added tasks] - - - [Clarifications for ambiguous tasks and questions if needed] - - - [Potential blockers with contingency actions and buffers] - - - [Milestones with go/no-go criteria and metrics] - - - - -[Brief reasoning for sequence, added tasks, and key decisions] - - -FAILURE -- Any required section (`` with its child tags, and ``) is missing or materially incomplete. -- Task sequence lacks dependencies, sequencing logic, or critical path indicators. -- Contingencies or decision criteria are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/task-list-optimization-and-contingency-based-project-planning/SKILL.md.tmpl b/skills/task-list-optimization-and-contingency-based-project-planning/SKILL.md.tmpl deleted file mode 100644 index 22e23e26..00000000 --- a/skills/task-list-optimization-and-contingency-based-project-planning/SKILL.md.tmpl +++ /dev/null @@ -1,76 +0,0 @@ ---- -name: task-list-optimization-and-contingency-based-project-planning -description: >- - Task list optimization and contingency-based project planning. Use when the user needs a - product workflow for project management related to task list optimization and - contingency-based project planning. Trigger terms: project-management, planning, scheduling, - risk-management. ---- -# Task list optimization and contingency-based project planning - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Task list optimization and contingency-based project planning**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TASK_LIST}} - - -GOAL -Produce a high-quality deliverable for: Task list optimization and contingency-based project planning. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze and optimize `{{TASK_LIST}}` by identifying dependencies, gaps, and ambiguities. -- Add missing tasks needed for completion and clarify ambiguous items. -- Sequence tasks for efficiency, highlight critical path, and assign rough durations. -- Identify resource constraints and opportunities for parallel execution. -- Build contingency plans with blockers, workarounds, and buffers. -- Define decision milestones with go/no-go criteria and metrics. -- Include a brief explanation of sequencing and key decisions. - -FORMAT -Return exactly this structure: - - - - [Sequenced tasks including dependencies, rough durations, critical path markers, and any added tasks] - - - [Clarifications for ambiguous tasks and questions if needed] - - - [Potential blockers with contingency actions and buffers] - - - [Milestones with go/no-go criteria and metrics] - - - - -[Brief reasoning for sequence, added tasks, and key decisions] - - -FAILURE -- Any required section (`` with its child tags, and ``) is missing or materially incomplete. -- Task sequence lacks dependencies, sequencing logic, or critical path indicators. -- Contingencies or decision criteria are missing or not actionable. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/task-list-optimization-and-contingency-based-project-planning/agents/openai.yaml b/skills/task-list-optimization-and-contingency-based-project-planning/agents/openai.yaml deleted file mode 100644 index 3a2e7fdb..00000000 --- a/skills/task-list-optimization-and-contingency-based-project-planning/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Task list optimization and contingency-based project planning" - short_description: "Task list optimization and contingency-based project planning. Use when the user needs a product workflow for..." - brand_color: "#7C3AED" - default_prompt: "Use $task-list-optimization-and-contingency-based-project-planning with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/task-list-optimization-and-contingency-based-project-planning/productize.json b/skills/task-list-optimization-and-contingency-based-project-planning/productize.json deleted file mode 100644 index 8faa5c91..00000000 --- a/skills/task-list-optimization-and-contingency-based-project-planning/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Task list optimization and contingency-based project planning", - "category": "Operations", - "lifecycle": "Plan", - "tags": [ - "task-list-optimization-and-contingency-based-project-planning", - "task", - "list", - "optimization", - "contingency", - "project", - "planning" - ], - "use_when": "Task list optimization and contingency-based project planning. Use when the user needs a product workflow for project management related to task list optimization and contingency-based project planning. Trigger terms: project-management, planning, scheduling, risk-management.", - "do_not_use_when": "Do not use Task list optimization and contingency-based project planning when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Task list optimization and contingency-based project planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "task-list-optimization-and-contingency-based-project-planning", - "task", - "list", - "optimization", - "contingency", - "project", - "planning" - ], - "framework_fit": "Task list optimization and contingency-based project planning fits Operations work in the Plan lifecycle when the user needs Task list optimization and contingency-based project planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Task list optimization and contingency-based project planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Task list optimization and contingency-based project planning as generic Operations advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Task list optimization and contingency-based project planning when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $task-list-optimization-and-contingency-based-project-planning to turn this task context into a decision-ready Task list optimization and contingency-based project planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Task list optimization and contingency-based project planning delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ] -} diff --git a/skills/task-specific-product-strategy-design/SKILL.md b/skills/task-specific-product-strategy-design/SKILL.md deleted file mode 100644 index 72d9a0da..00000000 --- a/skills/task-specific-product-strategy-design/SKILL.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -name: task-specific-product-strategy-design -description: >- - Task-specific product strategy design. Use when the user needs a product workflow for - product strategy related to task-specific product strategy design. Trigger terms: - product-management, strategy, prd, leadership, execution. ---- - - - -# Task-specific product strategy design - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `task-specific-product-strategy-design` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Task-specific product strategy design strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Task-specific product strategy design**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TASK_TYPE}} -- {{PRD_CONTENT}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: "Task-specific product strategy design". -Success metric: -- Detects the task type and produces the correct response structure. -- Grounds outputs in provided inputs and avoids generic advice. -- Delivers actionable, CPO-level guidance or PRD/analysis as requested. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if required content is missing for the chosen task type, state assumptions explicitly. -- If `{{TASK_TYPE}}` is unknown, ask a clarifying question within ``. -- Task-specific outputs: - - Draft PRD: include all required PRD sections in markdown. - - Analyze PRD: provide structured feedback across the listed aspects. - - General PM Advice: provide direct, experience-based guidance tied to user input. -- Avoid generic frameworks or platitudes. - -FORMAT -Return exactly this structure: - - -[Your detailed answer, following the task-specific instructions and communication style guidelines] - - -FAILURE -- `` wrapper is missing or malformed. -- Response does not match the requested task type. -- Draft PRD output omits required sections. -- Analysis feedback omits required review aspects. -- Advice is generic or not tied to `{{PM_QUESTION}}`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/task-specific-product-strategy-design/SKILL.md.tmpl b/skills/task-specific-product-strategy-design/SKILL.md.tmpl deleted file mode 100644 index db9ba65e..00000000 --- a/skills/task-specific-product-strategy-design/SKILL.md.tmpl +++ /dev/null @@ -1,62 +0,0 @@ ---- -name: task-specific-product-strategy-design -description: >- - Task-specific product strategy design. Use when the user needs a product workflow for - product strategy related to task-specific product strategy design. Trigger terms: - product-management, strategy, prd, leadership, execution. ---- -# Task-specific product strategy design - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Task-specific product strategy design**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TASK_TYPE}} -- {{PRD_CONTENT}} -- {{PM_QUESTION}} - - -GOAL -Produce a high-quality deliverable for: "Task-specific product strategy design". -Success metric: -- Detects the task type and produces the correct response structure. -- Grounds outputs in provided inputs and avoids generic advice. -- Delivers actionable, CPO-level guidance or PRD/analysis as requested. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if required content is missing for the chosen task type, state assumptions explicitly. -- If `{{TASK_TYPE}}` is unknown, ask a clarifying question within ``. -- Task-specific outputs: - - Draft PRD: include all required PRD sections in markdown. - - Analyze PRD: provide structured feedback across the listed aspects. - - General PM Advice: provide direct, experience-based guidance tied to user input. -- Avoid generic frameworks or platitudes. - -FORMAT -Return exactly this structure: - - -[Your detailed answer, following the task-specific instructions and communication style guidelines] - - -FAILURE -- `` wrapper is missing or malformed. -- Response does not match the requested task type. -- Draft PRD output omits required sections. -- Analysis feedback omits required review aspects. -- Advice is generic or not tied to `{{PM_QUESTION}}`. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/task-specific-product-strategy-design/agents/openai.yaml b/skills/task-specific-product-strategy-design/agents/openai.yaml deleted file mode 100644 index 918fa6f4..00000000 --- a/skills/task-specific-product-strategy-design/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Task-specific product strategy design" - short_description: "Task-specific product strategy design. Use when the user needs a product workflow for product strategy related to..." - brand_color: "#059669" - default_prompt: "Use $task-specific-product-strategy-design with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/task-specific-product-strategy-design/productize.json b/skills/task-specific-product-strategy-design/productize.json deleted file mode 100644 index 1fd5e13e..00000000 --- a/skills/task-specific-product-strategy-design/productize.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "title": "Task-specific product strategy design", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "task-specific-product-strategy-design", - "task", - "specific", - "design", - "use" - ], - "use_when": "Task-specific product strategy design. Use when the user needs a product workflow for product strategy related to task-specific product strategy design. Trigger terms: product-management, strategy, prd, leadership, execution.", - "do_not_use_when": "Do not use Task-specific product strategy design when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Task-specific product strategy design strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "task-specific-product-strategy-design", - "task", - "specific", - "design", - "use" - ], - "framework_fit": "Task-specific product strategy design fits Strategy work in the Strategize lifecycle when the user needs Task-specific product strategy design strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Task-specific product strategy design strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Task-specific product strategy design as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Task-specific product strategy design when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $task-specific-product-strategy-design to turn this task context into a decision-ready Task-specific product strategy design strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Task-specific product strategy design strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/tdd/SKILL.md b/skills/tdd/SKILL.md deleted file mode 100644 index c9f91b63..00000000 --- a/skills/tdd/SKILL.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -name: tdd -description: >- - Test-driven development: write a failing test first, then minimal code. Use before implementing - any feature or bugfix. ---- - - - -# Test-Driven Development (TDD) - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `tdd` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: TDD AI-builder handoff with implementation scope, verification plan, and risks - -Use when implementing any feature or bugfix, before writing implementation code. - -## Implementation Notes Hook - -If the user asks for a running implementation notes file, activate -`$implementation-notes` before writing production code. Keep the notes current -whenever a test or implementation choice interprets an ambiguous spec, departs -from the spec, accepts a tradeoff, or leaves an open question for the user. - -Do not let the notes file replace TDD. The test still comes first; the notes record -why the chosen behavior is the right interpretation of the spec. - -## The Iron Law - -``` -NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST -``` - -Write code before the test? Delete it. Start over. - -**No exceptions:** -- Don't keep it as "reference" -- Don't "adapt" it while writing tests -- Delete means delete - -## Red-Green-Refactor - -### RED - Write Failing Test -Write one minimal test showing what should happen. -- One behavior -- Clear name -- Real code (no mocks unless unavoidable) - -### Verify RED - Watch It Fail -**MANDATORY. Never skip.** -- Run the test, confirm it fails (not errors) -- Failure message is expected -- Test passes? You're testing existing behavior. Fix test. - -### GREEN - Minimal Code -Write simplest code to pass the test. -- Just enough to pass -- No extra features -- Don't add behavior beyond the test - -### Verify GREEN - Watch It Pass -**MANDATORY.** -- Test passes -- Other tests still pass -- Output pristine (no errors, warnings) - -### REFACTOR - Clean Up -After green only: -- Remove duplication -- Improve names -- Extract helpers -Keep tests green. Don't add behavior. - -## Why Order Matters - -**"I'll write tests after"** -Tests written after pass immediately. Passing immediately proves nothing. Test-first forces you to see the test fail, proving it actually tests something. - -**"Tests after achieve same goals"** -No. Tests-after answer "What does this do?" Tests-first answer "What should this do?" - -**"Deleting X hours of work is wasteful"** -Sunk cost fallacy. The time is gone. The waste is keeping code you can't trust. - -## Red Flags - STOP and Start Over - -- Code before test -- Test after implementation -- Test passes immediately -- "I already manually tested it" -- "Tests after achieve the same purpose" -- "This is different because..." - -**All mean: Delete code. Start over with TDD.** - -## Common Rationalizations - -| Excuse | Reality | -|--------|---------| -| "Too simple to test" | Simple code breaks. Test takes 30 seconds. | -| "I'll test after" | Tests passing immediately prove nothing. | -| "Already manually tested" | Ad-hoc is not systematic. No record, can't re-run. | -| "TDD will slow me down" | TDD faster than debugging later. | - -## Verification Checklist - -Before marking work complete: -- [ ] Every new function/method has a test -- [ ] Watched each test fail before implementing -- [ ] Each test failed for expected reason -- [ ] Wrote minimal code to pass each test -- [ ] All tests pass -- [ ] Output pristine (no errors, warnings) - -Can't check all boxes? You skipped TDD. Start over. - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/tdd/SKILL.md.tmpl b/skills/tdd/SKILL.md.tmpl deleted file mode 100644 index 74ff2418..00000000 --- a/skills/tdd/SKILL.md.tmpl +++ /dev/null @@ -1,118 +0,0 @@ ---- -name: tdd -description: >- - Test-driven development: write a failing test first, then minimal code. Use before implementing - any feature or bugfix. ---- -# Test-Driven Development (TDD) - -{{PRODUCTIZE_PREAMBLE}} - -Use when implementing any feature or bugfix, before writing implementation code. - -## Implementation Notes Hook - -If the user asks for a running implementation notes file, activate -`$implementation-notes` before writing production code. Keep the notes current -whenever a test or implementation choice interprets an ambiguous spec, departs -from the spec, accepts a tradeoff, or leaves an open question for the user. - -Do not let the notes file replace TDD. The test still comes first; the notes record -why the chosen behavior is the right interpretation of the spec. - -## The Iron Law - -``` -NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST -``` - -Write code before the test? Delete it. Start over. - -**No exceptions:** -- Don't keep it as "reference" -- Don't "adapt" it while writing tests -- Delete means delete - -## Red-Green-Refactor - -### RED - Write Failing Test -Write one minimal test showing what should happen. -- One behavior -- Clear name -- Real code (no mocks unless unavoidable) - -### Verify RED - Watch It Fail -**MANDATORY. Never skip.** -- Run the test, confirm it fails (not errors) -- Failure message is expected -- Test passes? You're testing existing behavior. Fix test. - -### GREEN - Minimal Code -Write simplest code to pass the test. -- Just enough to pass -- No extra features -- Don't add behavior beyond the test - -### Verify GREEN - Watch It Pass -**MANDATORY.** -- Test passes -- Other tests still pass -- Output pristine (no errors, warnings) - -### REFACTOR - Clean Up -After green only: -- Remove duplication -- Improve names -- Extract helpers -Keep tests green. Don't add behavior. - -## Why Order Matters - -**"I'll write tests after"** -Tests written after pass immediately. Passing immediately proves nothing. Test-first forces you to see the test fail, proving it actually tests something. - -**"Tests after achieve same goals"** -No. Tests-after answer "What does this do?" Tests-first answer "What should this do?" - -**"Deleting X hours of work is wasteful"** -Sunk cost fallacy. The time is gone. The waste is keeping code you can't trust. - -## Red Flags - STOP and Start Over - -- Code before test -- Test after implementation -- Test passes immediately -- "I already manually tested it" -- "Tests after achieve the same purpose" -- "This is different because..." - -**All mean: Delete code. Start over with TDD.** - -## Common Rationalizations - -| Excuse | Reality | -|--------|---------| -| "Too simple to test" | Simple code breaks. Test takes 30 seconds. | -| "I'll test after" | Tests passing immediately prove nothing. | -| "Already manually tested" | Ad-hoc is not systematic. No record, can't re-run. | -| "TDD will slow me down" | TDD faster than debugging later. | - -## Verification Checklist - -Before marking work complete: -- [ ] Every new function/method has a test -- [ ] Watched each test fail before implementing -- [ ] Each test failed for expected reason -- [ ] Wrote minimal code to pass each test -- [ ] All tests pass -- [ ] Output pristine (no errors, warnings) - -Can't check all boxes? You skipped TDD. Start over. - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/tdd/agents/openai.yaml b/skills/tdd/agents/openai.yaml deleted file mode 100644 index 88f82cbd..00000000 --- a/skills/tdd/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "TDD" - short_description: "Test-driven development: write a failing test first, then minimal code. Use before implementing any feature or bugfix." - brand_color: "#334155" - default_prompt: "Use $tdd with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/tdd/productize.json b/skills/tdd/productize.json deleted file mode 100644 index 755e712c..00000000 --- a/skills/tdd/productize.json +++ /dev/null @@ -1,47 +0,0 @@ -{ - "title": "TDD", - "category": "AI Execution", - "tags": [ - "tdd", - "testing", - "red-green-refactor", - "bugfix", - "feature-development", - "verification", - "technical", - "test", - "driven", - "development", - "write", - "failing", - "first", - "execution" - ], - "lifecycle": "Build With AI", - "use_when": "Test-driven development: write a failing test first, then minimal code. Use before implementing any feature or bugfix.", - "do_not_use_when": "Do not use TDD when the request is mainly market strategy, research synthesis, finance modeling, or executive communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "TDD AI-builder handoff with implementation scope, verification plan, and risks", - "routing_signals": [ - "tdd", - "technical", - "test", - "driven", - "development", - "write", - "failing", - "first", - "execution" - ], - "framework_fit": "TDD fits AI Execution work in the Build With AI lifecycle when the user needs TDD AI-builder handoff with implementation scope, verification plan, and risks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces TDD AI-builder handoff with implementation scope, verification plan, and risks without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats TDD as generic AI Execution advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from TDD when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $tdd to turn this technical context into a decision-ready TDD AI-builder handoff with implementation scope, verification plan, and risks.", - "expected_artifact": "TDD AI-builder handoff with implementation scope, verification plan, and risks" - } - ] -} diff --git a/skills/technical-architecture-brief-from-product-requirements-doc/SKILL.md b/skills/technical-architecture-brief-from-product-requirements-doc/SKILL.md deleted file mode 100644 index 695ca3a1..00000000 --- a/skills/technical-architecture-brief-from-product-requirements-doc/SKILL.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -name: technical-architecture-brief-from-product-requirements-doc -description: >- - Technical architecture brief from product requirements doc. Use when the user needs a - product workflow for technical related to technical architecture brief from product - requirements doc. Trigger terms: software-architecture, startup-cto, systems-design, - risk-management, technical. ---- - - - -# Technical architecture brief from product requirements doc - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `technical-architecture-brief-from-product-requirements-doc` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: AI Execution architecture brief for agent or engineering implementation - -Use this skill to run the Productize prompt contract for **Technical architecture brief from product requirements doc**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRD}} - - -GOAL -Produce a high-quality deliverable for: Technical architecture brief from product requirements doc. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Create a comprehensive Technical Architecture Brief from `{{PRD}}` suitable for startup execution. -- Include and reason through all required sections: -- `System Context Diagram` -- Bounded contexts. -- Context interactions. -- Third-party integrations (APIs/SaaS/data pipelines). -- `Component Architecture` -- Monolith vs microservices trade-off. -- Recommended architecture with justification. -- Data flow, schema, and caching strategy. -- Database choice rationale (relational/NoSQL/hybrid). -- `Technology Stack Rationale` -- Frontend/backend framework recommendations with rationale. -- Infrastructure approach (cloud/on-prem/hybrid). -- Containerization and CI/CD strategy. -- `Risk Mitigation Plan` -- Failure modes and single points of failure. -- Redundancy and resilience strategies. -- High-level compute/storage cost projections aligned to growth. -- Keep recommendations tied to the PRD and explicitly state assumptions when PRD details are missing. - -FORMAT -Return exactly this structure: - - - -[Content for this section] - - - -[Content for this section] - - - -[Content for this section] - - - -[Content for this section] - - - -FAILURE -- `` wrapper or any required section is missing/malformed/materially incomplete. -- Recommendations are generic and not traceable to the provided PRD. -- Architecture choice lacks explicit trade-off analysis (monolith vs microservices). -- Risk plan lacks concrete failure modes, mitigation strategy, or cost-growth framing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/technical-architecture-brief-from-product-requirements-doc/SKILL.md.tmpl b/skills/technical-architecture-brief-from-product-requirements-doc/SKILL.md.tmpl deleted file mode 100644 index a943f0ff..00000000 --- a/skills/technical-architecture-brief-from-product-requirements-doc/SKILL.md.tmpl +++ /dev/null @@ -1,89 +0,0 @@ ---- -name: technical-architecture-brief-from-product-requirements-doc -description: >- - Technical architecture brief from product requirements doc. Use when the user needs a - product workflow for technical related to technical architecture brief from product - requirements doc. Trigger terms: software-architecture, startup-cto, systems-design, - risk-management, technical. ---- -# Technical architecture brief from product requirements doc - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Technical architecture brief from product requirements doc**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRD}} - - -GOAL -Produce a high-quality deliverable for: Technical architecture brief from product requirements doc. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Create a comprehensive Technical Architecture Brief from `{{PRD}}` suitable for startup execution. -- Include and reason through all required sections: -- `System Context Diagram` -- Bounded contexts. -- Context interactions. -- Third-party integrations (APIs/SaaS/data pipelines). -- `Component Architecture` -- Monolith vs microservices trade-off. -- Recommended architecture with justification. -- Data flow, schema, and caching strategy. -- Database choice rationale (relational/NoSQL/hybrid). -- `Technology Stack Rationale` -- Frontend/backend framework recommendations with rationale. -- Infrastructure approach (cloud/on-prem/hybrid). -- Containerization and CI/CD strategy. -- `Risk Mitigation Plan` -- Failure modes and single points of failure. -- Redundancy and resilience strategies. -- High-level compute/storage cost projections aligned to growth. -- Keep recommendations tied to the PRD and explicitly state assumptions when PRD details are missing. - -FORMAT -Return exactly this structure: - - - -[Content for this section] - - - -[Content for this section] - - - -[Content for this section] - - - -[Content for this section] - - - -FAILURE -- `` wrapper or any required section is missing/malformed/materially incomplete. -- Recommendations are generic and not traceable to the provided PRD. -- Architecture choice lacks explicit trade-off analysis (monolith vs microservices). -- Risk plan lacks concrete failure modes, mitigation strategy, or cost-growth framing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/technical-architecture-brief-from-product-requirements-doc/agents/openai.yaml b/skills/technical-architecture-brief-from-product-requirements-doc/agents/openai.yaml deleted file mode 100644 index f84dd722..00000000 --- a/skills/technical-architecture-brief-from-product-requirements-doc/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "AI Execution architecture brief from product requirements doc" - short_description: "Technical architecture brief from product requirements doc. Use when the user needs a product workflow for technical..." - brand_color: "#334155" - default_prompt: "Use $technical-architecture-brief-from-product-requirements-doc with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/technical-architecture-brief-from-product-requirements-doc/productize.json b/skills/technical-architecture-brief-from-product-requirements-doc/productize.json deleted file mode 100644 index 2ffa4052..00000000 --- a/skills/technical-architecture-brief-from-product-requirements-doc/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "AI Execution architecture brief from product requirements doc", - "category": "AI Execution", - "lifecycle": "Build With AI", - "tags": [ - "technical-architecture-brief-from-product-requirements-doc", - "technical", - "architecture", - "brief", - "requirements", - "doc", - "execution" - ], - "use_when": "AI Execution architecture brief from product requirements doc. Use when the user needs a product workflow for technical related to technical architecture brief from product requirements doc. Trigger terms: software-architecture, startup-cto, systems-design, risk-management, technical.", - "do_not_use_when": "Do not use AI Execution architecture brief from product requirements doc when the request is mainly market strategy, research synthesis, finance modeling, or executive communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "AI Execution architecture brief for agent or engineering implementation", - "routing_signals": [ - "technical-architecture-brief-from-product-requirements-doc", - "technical", - "architecture", - "brief", - "requirements", - "doc", - "execution" - ], - "framework_fit": "Appropriate when product requirements need to become implementation architecture, system boundaries, technical risks, and build sequencing.", - "failure_modes": [ - "Produces AI Execution architecture brief for agent or engineering implementation without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats AI Execution architecture brief from product requirements doc as generic AI Execution advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from AI Execution architecture brief from product requirements doc when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $technical-architecture-brief-from-product-requirements-doc to turn this technical context into a decision-ready AI Execution architecture brief for agent or engineering implementation.", - "expected_artifact": "AI Execution architecture brief for agent or engineering implementation" - } - ] -} diff --git a/skills/technical-translation-and-stakeholder-communication/SKILL.md b/skills/technical-translation-and-stakeholder-communication/SKILL.md deleted file mode 100644 index 3c56ac1a..00000000 --- a/skills/technical-translation-and-stakeholder-communication/SKILL.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -name: technical-translation-and-stakeholder-communication -description: >- - Technical Translation and Stakeholder Communication. Use when the user needs a product - workflow for stakeholder management related to technical translation and stakeholder - communication. Trigger terms: stakeholder-management, technical-communication, - product-management, decision-making. ---- - - - -# Technical Translation and Stakeholder Communication - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `technical-translation-and-stakeholder-communication` -- **Lifecycle**: Align -- **Category**: Stakeholder Communication -- **Primary artifact**: AI Execution Translation and Stakeholder Communication stakeholder narrative with audience, message, risks, asks, and follow-up owner - -Use this skill to run the Productize prompt contract for **Technical Translation and Stakeholder Communication**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TECHNICAL_EXPLANATION}} -- {{STAKEHOLDER_TYPE}} - - -GOAL -Produce a high-quality deliverable for: Technical Translation and Stakeholder Communication. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Translate `{{TECHNICAL_EXPLANATION}}` for `{{STAKEHOLDER_TYPE}}` into clear, decision-ready language. -- Preserve core technical meaning while reducing jargon and using relatable explanations where helpful. -- Explicitly cover: -- Overview of the technical situation. -- Business impact in stakeholder terms. -- Important considerations (risks, benefits, decisions). -- Likely stakeholder questions with direct answers. -- Recommended next steps. -- Include a brief glossary only for unavoidable technical terms. -- Final output must include only `` and ``. - -FORMAT -Return exactly this structure: - - -1. Overview: [Brief description of the technical situation] -2. Business Impact: [Key implications for the stakeholder] -3. Important Considerations: [Risks, benefits, or decisions to understand] -4. Stakeholder Questions and Answers: - Q1: [Likely question 1] - A1: [Clear answer to question 1] - Q2: [Likely question 2] - A2: [Clear answer to question 2] - [Add more Q&A pairs as needed] -5. Next Steps: [Recommended actions, if applicable] - - - -- Term 1: [Brief definition] -- Term 2: [Brief definition] -[Add more terms as needed] - - -FAILURE -- `` or `` is missing, malformed, or materially incomplete. -- Explanation is still jargon-heavy for the specified stakeholder type. -- Q&A section is missing or does not address likely stakeholder concerns. -- Translation loses critical risks/implications from the original technical content. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/technical-translation-and-stakeholder-communication/SKILL.md.tmpl b/skills/technical-translation-and-stakeholder-communication/SKILL.md.tmpl deleted file mode 100644 index 3ef2d9eb..00000000 --- a/skills/technical-translation-and-stakeholder-communication/SKILL.md.tmpl +++ /dev/null @@ -1,81 +0,0 @@ ---- -name: technical-translation-and-stakeholder-communication -description: >- - Technical Translation and Stakeholder Communication. Use when the user needs a product - workflow for stakeholder management related to technical translation and stakeholder - communication. Trigger terms: stakeholder-management, technical-communication, - product-management, decision-making. ---- -# Technical Translation and Stakeholder Communication - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Technical Translation and Stakeholder Communication**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{TECHNICAL_EXPLANATION}} -- {{STAKEHOLDER_TYPE}} - - -GOAL -Produce a high-quality deliverable for: Technical Translation and Stakeholder Communication. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Translate `{{TECHNICAL_EXPLANATION}}` for `{{STAKEHOLDER_TYPE}}` into clear, decision-ready language. -- Preserve core technical meaning while reducing jargon and using relatable explanations where helpful. -- Explicitly cover: -- Overview of the technical situation. -- Business impact in stakeholder terms. -- Important considerations (risks, benefits, decisions). -- Likely stakeholder questions with direct answers. -- Recommended next steps. -- Include a brief glossary only for unavoidable technical terms. -- Final output must include only `` and ``. - -FORMAT -Return exactly this structure: - - -1. Overview: [Brief description of the technical situation] -2. Business Impact: [Key implications for the stakeholder] -3. Important Considerations: [Risks, benefits, or decisions to understand] -4. Stakeholder Questions and Answers: - Q1: [Likely question 1] - A1: [Clear answer to question 1] - Q2: [Likely question 2] - A2: [Clear answer to question 2] - [Add more Q&A pairs as needed] -5. Next Steps: [Recommended actions, if applicable] - - - -- Term 1: [Brief definition] -- Term 2: [Brief definition] -[Add more terms as needed] - - -FAILURE -- `` or `` is missing, malformed, or materially incomplete. -- Explanation is still jargon-heavy for the specified stakeholder type. -- Q&A section is missing or does not address likely stakeholder concerns. -- Translation loses critical risks/implications from the original technical content. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/technical-translation-and-stakeholder-communication/agents/openai.yaml b/skills/technical-translation-and-stakeholder-communication/agents/openai.yaml deleted file mode 100644 index 988c40e0..00000000 --- a/skills/technical-translation-and-stakeholder-communication/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "AI Execution Translation and Stakeholder Communication" - short_description: "Technical Translation and Stakeholder Communication. Use when the user needs a product workflow for stakeholder..." - brand_color: "#0891B2" - default_prompt: "Use $technical-translation-and-stakeholder-communication with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/technical-translation-and-stakeholder-communication/productize.json b/skills/technical-translation-and-stakeholder-communication/productize.json deleted file mode 100644 index 3b181e20..00000000 --- a/skills/technical-translation-and-stakeholder-communication/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "AI Execution Translation and Stakeholder Communication", - "category": "Stakeholder Communication", - "lifecycle": "Align", - "tags": [ - "technical-translation-and-stakeholder-communication", - "technical", - "translation", - "stakeholder", - "communication", - "management", - "execution" - ], - "use_when": "AI Execution Translation and Stakeholder Communication. Use when the user needs a product workflow for stakeholder management related to technical translation and stakeholder communication. Trigger terms: stakeholder-management, technical-communication, product-management, decision-making.", - "do_not_use_when": "Do not use AI Execution Translation and Stakeholder Communication when the request is mainly technical implementation, analytics modeling, or UX critique; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "AI Execution Translation and Stakeholder Communication stakeholder narrative with audience, message, risks, asks, and follow-up owner", - "routing_signals": [ - "technical-translation-and-stakeholder-communication", - "technical", - "translation", - "stakeholder", - "communication", - "management", - "execution" - ], - "framework_fit": "AI Execution Translation and Stakeholder Communication fits Stakeholder Communication work in the Align lifecycle when the user needs AI Execution Translation and Stakeholder Communication stakeholder narrative with audience, message, risks, asks, and follow-up owner and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces AI Execution Translation and Stakeholder Communication stakeholder narrative with audience, message, risks, asks, and follow-up owner without tying recommendations to the user's Align stage, evidence, and decision pressure.", - "Treats AI Execution Translation and Stakeholder Communication as generic Stakeholder Communication advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from AI Execution Translation and Stakeholder Communication when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $technical-translation-and-stakeholder-communication to turn this technical context into a decision-ready AI Execution Translation and Stakeholder Communication stakeholder narrative with audience, message, risks, asks, and follow-up owner.", - "expected_artifact": "AI Execution Translation and Stakeholder Communication stakeholder narrative with audience, message, risks, asks, and follow-up owner" - } - ] -} diff --git a/skills/test-scenarios/SKILL.md b/skills/test-scenarios/SKILL.md deleted file mode 100644 index 90a0defb..00000000 --- a/skills/test-scenarios/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: test-scenarios -description: >- - Test Scenarios. Use when creating test scenarios from user stories, feature specs, PRDs, - acceptance criteria, or agent-ready implementation plans. ---- - - - -# Test Scenarios - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `test-scenarios` -- **Lifecycle**: Build With AI -- **Category**: Delivery -- **Primary artifact**: QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix - -Use when creating test scenarios from user stories, feature specs, PRDs, acceptance criteria, or agent-ready implementation plans. - -## Productize Contract - -- **Primary lifecycle**: Build With AI -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix -- **Source method**: pm-skills-main/pm-execution/skills/test-scenarios/SKILL.md - -## Method - -Create comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step test actions, and expected outcomes. - -**Use when:** Writing QA test cases, creating test plans, defining acceptance test scenarios, or validating user story implementations. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$USER_STORY`: The user story to test (title and acceptance criteria) -- `$CONTEXT`: Additional testing context or constraints - -## Step-by-Step Process - -1. **Review the user story** and acceptance criteria -2. **Define test objectives** - What specific behavior to validate -3. **Establish starting conditions** - System state, data setup, configurations -4. **Identify user roles** - Who performs the test actions -5. **Create test steps** - Break down interactions step-by-step -6. **Define expected outcomes** - Observable results after each step -7. **Consider edge cases** - Invalid inputs, boundary conditions -8. **Output detailed test scenarios** - Ready for QA execution - -## Scenario Template - -**Test Scenario:** [Clear scenario name] - -**Test Objective:** [What this test validates] - -**Starting Conditions:** -- [System state required] -- [Data or configuration needed] -- [User setup or permissions] - -**User Role:** [Who performs the test] - -**Test Steps:** -1. [First action and its expected result] -2. [Second action and observable outcome] -3. [Third action and system behavior] -4. [Completion action and final state] - -**Expected Outcomes:** -- [Observable result 1] -- [Observable result 2] -- [Observable result 3] - -## Example Test Scenario - -**Test Scenario:** View Recently Viewed Products on Product Page - -**Test Objective:** Verify that the 'Recently viewed' section displays correctly and excludes the current product. - -**Starting Conditions:** -- User is logged in or has browser history enabled -- User has viewed at least 2 products in the current session -- User is now on a product page different from previously viewed items - -**User Role:** Online Shopper - -**Test Steps:** -1. Navigate to any product page -> Section should appear at bottom with previously viewed items -2. Scroll to bottom of page -> "Recently viewed" section is visible with product cards -3. Verify product thumbnails -> Images, titles, and prices are displayed correctly -4. Check current product -> Current product is NOT in the recently viewed list -5. Click on a product card -> User navigates to the corresponding product page - -**Expected Outcomes:** -- Recently viewed section appears only after viewing at least 1 prior product -- Section displays 4-8 product cards with complete information -- Current product is excluded from the list -- Each card shows "Viewed X minutes/hours ago" timestamp -- Clicking cards navigates to correct product pages -- Performance: Section loads within 2 seconds - -## Output Deliverables - -- Comprehensive test scenarios for each acceptance criterion -- Clear test objectives aligned with user story intent -- Detailed step-by-step test actions -- Observable expected outcomes after each step -- Edge case and error scenario coverage -- Ready for QA team execution and documentation - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/test-scenarios/SKILL.md.tmpl b/skills/test-scenarios/SKILL.md.tmpl deleted file mode 100644 index 42b65de8..00000000 --- a/skills/test-scenarios/SKILL.md.tmpl +++ /dev/null @@ -1,108 +0,0 @@ ---- -name: test-scenarios -description: >- - Test Scenarios. Use when creating test scenarios from user stories, feature specs, PRDs, - acceptance criteria, or agent-ready implementation plans. ---- -# Test Scenarios - -{{PRODUCTIZE_PREAMBLE}} - -Use when creating test scenarios from user stories, feature specs, PRDs, acceptance criteria, or agent-ready implementation plans. - -## Productize Contract - -- **Primary lifecycle**: Build With AI -- **Supporting lifecycle**: Launch & Learn -- **Primary artifact**: QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix -- **Source method**: pm-skills-main/pm-execution/skills/test-scenarios/SKILL.md - -## Method - -Create comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step test actions, and expected outcomes. - -**Use when:** Writing QA test cases, creating test plans, defining acceptance test scenarios, or validating user story implementations. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$USER_STORY`: The user story to test (title and acceptance criteria) -- `$CONTEXT`: Additional testing context or constraints - -## Step-by-Step Process - -1. **Review the user story** and acceptance criteria -2. **Define test objectives** - What specific behavior to validate -3. **Establish starting conditions** - System state, data setup, configurations -4. **Identify user roles** - Who performs the test actions -5. **Create test steps** - Break down interactions step-by-step -6. **Define expected outcomes** - Observable results after each step -7. **Consider edge cases** - Invalid inputs, boundary conditions -8. **Output detailed test scenarios** - Ready for QA execution - -## Scenario Template - -**Test Scenario:** [Clear scenario name] - -**Test Objective:** [What this test validates] - -**Starting Conditions:** -- [System state required] -- [Data or configuration needed] -- [User setup or permissions] - -**User Role:** [Who performs the test] - -**Test Steps:** -1. [First action and its expected result] -2. [Second action and observable outcome] -3. [Third action and system behavior] -4. [Completion action and final state] - -**Expected Outcomes:** -- [Observable result 1] -- [Observable result 2] -- [Observable result 3] - -## Example Test Scenario - -**Test Scenario:** View Recently Viewed Products on Product Page - -**Test Objective:** Verify that the 'Recently viewed' section displays correctly and excludes the current product. - -**Starting Conditions:** -- User is logged in or has browser history enabled -- User has viewed at least 2 products in the current session -- User is now on a product page different from previously viewed items - -**User Role:** Online Shopper - -**Test Steps:** -1. Navigate to any product page -> Section should appear at bottom with previously viewed items -2. Scroll to bottom of page -> "Recently viewed" section is visible with product cards -3. Verify product thumbnails -> Images, titles, and prices are displayed correctly -4. Check current product -> Current product is NOT in the recently viewed list -5. Click on a product card -> User navigates to the corresponding product page - -**Expected Outcomes:** -- Recently viewed section appears only after viewing at least 1 prior product -- Section displays 4-8 product cards with complete information -- Current product is excluded from the list -- Each card shows "Viewed X minutes/hours ago" timestamp -- Clicking cards navigates to correct product pages -- Performance: Section loads within 2 seconds - -## Output Deliverables - -- Comprehensive test scenarios for each acceptance criterion -- Clear test objectives aligned with user story intent -- Detailed step-by-step test actions -- Observable expected outcomes after each step -- Edge case and error scenario coverage -- Ready for QA team execution and documentation - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/test-scenarios/agents/openai.yaml b/skills/test-scenarios/agents/openai.yaml deleted file mode 100644 index 85eb3f2d..00000000 --- a/skills/test-scenarios/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Test Scenarios" - short_description: "Test Scenarios. Use when creating test scenarios from user stories, feature specs, PRDs, acceptance criteria, or..." - brand_color: "#4F46E5" - default_prompt: "Use $test-scenarios with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/test-scenarios/productize.json b/skills/test-scenarios/productize.json deleted file mode 100644 index 3cc26336..00000000 --- a/skills/test-scenarios/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Test Scenarios", - "category": "Delivery", - "lifecycle": "Build With AI", - "tags": [ - "test-scenarios", - "qa", - "acceptance-tests", - "user-stories", - "validation", - "edge-cases", - "launch-and-learn", - "test", - "scenarios", - "technical", - "use", - "creating", - "delivery" - ], - "use_when": "Use when creating test scenarios from user stories, feature specs, PRDs, acceptance criteria, or agent-ready implementation plans.", - "do_not_use_when": "Do not use for broad product verification strategy, unit test implementation, or post-launch metrics analysis.", - "output_artifact": "QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix", - "routing_signals": [ - "test-scenarios", - "qa", - "acceptance-tests", - "user-stories", - "validation", - "edge-cases", - "when", - "creating", - "test", - "scenarios", - "from", - "user", - "stories", - "feature" - ], - "framework_fit": "Best when product requirements need to become concrete QA or acceptance scenarios before build or release.", - "failure_modes": [ - "Produces QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats Test Scenarios as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Test Scenarios when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $test-scenarios to turn this qa context into a decision-ready QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix.", - "expected_artifact": "QA-ready test scenarios with roles, preconditions, steps, expected outcomes, and coverage matrix" - } - ], - "imported_from": "pm-skills-main/pm-execution/skills/test-scenarios/SKILL.md" -} diff --git a/skills/thesis-review/SKILL.md b/skills/thesis-review/SKILL.md deleted file mode 100644 index 0d938381..00000000 --- a/skills/thesis-review/SKILL.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -name: thesis-review -description: >- - Product thesis gate for new bets, capability scope, wedge, market, positioning, - pricing, and kill-or-continue decisions. Use before committing build or growth - effort to a product direction. ---- - - - -# Thesis Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `thesis-review` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Thesis review with product thesis, evidence map, challenge, decision, and next gate - -Use this gate to test whether the product thesis is worth continuing. It asks if -the user, problem, wedge, competitive position, value capture, and evidence standard -are coherent enough for the next playbook move. - -This is the Productize equivalent of a founder/CEO plan challenge. It is not a -strategy memo generator. Its job is to force a decision: proceed, narrow, validate, -pivot, pause, or kill. - -## Artifact Format - -Use Markdown for a short gate decision. Use self-contained HTML when the thesis -review needs a shareable decision dashboard, evidence map, wedge comparison, -positioning/pricing table, risk heatmap, or long kill/continue rationale. HTML -should make the decision easier to review, not turn the gate into a slide deck. - -## Pre-Review Audit - -Before judging the thesis: - -1. Read the current request, prior Productize artifacts, repo docs, plans, research, - metrics, TODOs, and any shipped behavior that constrain the bet. -2. Identify whether this is a new `$0-1` bet, a growth pivot, an operate escalation, - or a scope-change review inside an active plan. -3. Separate user-provided facts from assumptions and model inference. -4. Check for stale artifacts: if the thesis relies on a plan, research note, metric, - design, or release state that predates meaningful changes, mark it stale. -5. Name the blocked decision in one sentence before reviewing. If there is no - decision to make, route to the tactical routed skill instead of running this gate. - -## Mode Selection - -Choose one mode and state why: - -- **Expansion**: the current thesis is too small for the opportunity; explore 10x - outcomes, then cherry-pick only concrete additions worth testing now. -- **Selective Expansion**: keep the core scope, but evaluate a short list of - high-leverage additions. -- **Hold Scope**: the bet is directionally right; pressure-test evidence, risks, - and execution without expanding. -- **Reduction**: the thesis is too broad; cut to the smallest bet that can prove - or disprove value. -- **Kill/Pause**: the evidence gap, market structure, or user pull is too weak to - justify more build/growth effort. - -When a mode creates a real scope decision, handle one proposal at a time. For each: -state the proposal, why it matters, effort/risk, recommendation, and decision. Do -not batch unrelated scope choices. - -## Review Passes - -### 1. Premise Challenge - -- What must be true for this to matter? -- Who specifically has the pain, budget, urgency, and switching pressure? -- What would make this obviously wrong within two weeks? -- What existing behavior, customer quote, metric, or market fact supports it? - -### 2. Wedge And Beachhead - -- Is the first segment narrow enough to find, message, serve, and learn from? -- Is the job/pain acute enough to overcome inertia? -- Does the wedge create a path to the broader product, or is it a dead end? -- What adjacent segment should be explicitly out of scope? - -### 3. Positioning And Competitive Alternative - -- What does the user do today instead? -- What category will they compare this against? -- What is the sharpest differentiated claim Productize can defend with evidence? -- What claim should not be made yet? - -### 4. Value Capture - -- What is the value metric or pricing hypothesis? -- What budget, willingness-to-pay, or cost-of-delay evidence exists? -- What packaging risk could make adoption or expansion fail? -- What pricing/monetization assumption needs validation before scale? - -### 5. Evidence And Risk Register - -Create a compact risk register: - -| Risk | Assumption | Evidence today | Test | Decision threshold | -|---|---|---|---|---| - -Include at least one demand risk, usability risk, feasibility risk, data/eval risk, -and GTM/value-capture risk when applicable. - -### 6. System And Rollout Implications - -- What existing product/code/data can be reused? -- What new surface area does this create for design, engineering, QA, docs, DX, or - comms? -- If this ships and fails, what is the rollback, learning, or kill path? -- What should be instrumented before the next gate? - -## Decision Protocol - -For each substantive issue: - -- State the issue and evidence. -- Offer the smallest viable correction. -- Recommend one option and explain why. -- If the decision materially changes scope, ask or record the decision explicitly. -- If the fix is obvious and low-risk, state it and continue. - -Never silently default unresolved thesis decisions. List them in the final output -as unresolved decisions that may change downstream work. - -## Route Internally - -- `$market-opportunity` -- `$beachhead-segment` -- `$competitive-analysis-to-winning-positioning-strategy` -- `$product-assumptions-from-core-strategy-inputs` -- `$risky-assumption-prioritization-for-rapid-validation` -- `$pre-mortem` -- `$strategic-crux-diagnosis-and-strategy-design` - -## Required Output - -Return: - -1. **Thesis**: user, problem, wedge, position, price/value capture, and why now. -2. **Evidence Map**: facts, assumptions, missing evidence, and riskiest leap. -3. **Mode And Scope Decision**: expansion, selective expansion, hold, reduction, pause, or kill; include accepted/deferred/skipped changes. -4. **Challenge**: strongest reason this thesis may be wrong and the fastest way to learn. -5. **Risk Register**: assumptions, evidence, tests, thresholds, and owner. -6. **Decision**: proceed, narrow, validate, pivot, pause, or kill. -7. **Next Gate**: product, design, eng, QA, release, docs, DX, or comms gate if needed; flag stale gates. -8. **Completion Summary**: status, confidence, unresolved decisions, and what would change your mind. diff --git a/skills/thesis-review/SKILL.md.tmpl b/skills/thesis-review/SKILL.md.tmpl deleted file mode 100644 index 25e02303..00000000 --- a/skills/thesis-review/SKILL.md.tmpl +++ /dev/null @@ -1,142 +0,0 @@ ---- -name: thesis-review -description: >- - Product thesis gate for new bets, capability scope, wedge, market, positioning, - pricing, and kill-or-continue decisions. Use before committing build or growth - effort to a product direction. ---- -# Thesis Review - -{{PRODUCTIZE_PREAMBLE}} - -Use this gate to test whether the product thesis is worth continuing. It asks if -the user, problem, wedge, competitive position, value capture, and evidence standard -are coherent enough for the next playbook move. - -This is the Productize equivalent of a founder/CEO plan challenge. It is not a -strategy memo generator. Its job is to force a decision: proceed, narrow, validate, -pivot, pause, or kill. - -## Artifact Format - -Use Markdown for a short gate decision. Use self-contained HTML when the thesis -review needs a shareable decision dashboard, evidence map, wedge comparison, -positioning/pricing table, risk heatmap, or long kill/continue rationale. HTML -should make the decision easier to review, not turn the gate into a slide deck. - -## Pre-Review Audit - -Before judging the thesis: - -1. Read the current request, prior Productize artifacts, repo docs, plans, research, - metrics, TODOs, and any shipped behavior that constrain the bet. -2. Identify whether this is a new `$0-1` bet, a growth pivot, an operate escalation, - or a scope-change review inside an active plan. -3. Separate user-provided facts from assumptions and model inference. -4. Check for stale artifacts: if the thesis relies on a plan, research note, metric, - design, or release state that predates meaningful changes, mark it stale. -5. Name the blocked decision in one sentence before reviewing. If there is no - decision to make, route to the tactical routed skill instead of running this gate. - -## Mode Selection - -Choose one mode and state why: - -- **Expansion**: the current thesis is too small for the opportunity; explore 10x - outcomes, then cherry-pick only concrete additions worth testing now. -- **Selective Expansion**: keep the core scope, but evaluate a short list of - high-leverage additions. -- **Hold Scope**: the bet is directionally right; pressure-test evidence, risks, - and execution without expanding. -- **Reduction**: the thesis is too broad; cut to the smallest bet that can prove - or disprove value. -- **Kill/Pause**: the evidence gap, market structure, or user pull is too weak to - justify more build/growth effort. - -When a mode creates a real scope decision, handle one proposal at a time. For each: -state the proposal, why it matters, effort/risk, recommendation, and decision. Do -not batch unrelated scope choices. - -## Review Passes - -### 1. Premise Challenge - -- What must be true for this to matter? -- Who specifically has the pain, budget, urgency, and switching pressure? -- What would make this obviously wrong within two weeks? -- What existing behavior, customer quote, metric, or market fact supports it? - -### 2. Wedge And Beachhead - -- Is the first segment narrow enough to find, message, serve, and learn from? -- Is the job/pain acute enough to overcome inertia? -- Does the wedge create a path to the broader product, or is it a dead end? -- What adjacent segment should be explicitly out of scope? - -### 3. Positioning And Competitive Alternative - -- What does the user do today instead? -- What category will they compare this against? -- What is the sharpest differentiated claim Productize can defend with evidence? -- What claim should not be made yet? - -### 4. Value Capture - -- What is the value metric or pricing hypothesis? -- What budget, willingness-to-pay, or cost-of-delay evidence exists? -- What packaging risk could make adoption or expansion fail? -- What pricing/monetization assumption needs validation before scale? - -### 5. Evidence And Risk Register - -Create a compact risk register: - -| Risk | Assumption | Evidence today | Test | Decision threshold | -|---|---|---|---|---| - -Include at least one demand risk, usability risk, feasibility risk, data/eval risk, -and GTM/value-capture risk when applicable. - -### 6. System And Rollout Implications - -- What existing product/code/data can be reused? -- What new surface area does this create for design, engineering, QA, docs, DX, or - comms? -- If this ships and fails, what is the rollback, learning, or kill path? -- What should be instrumented before the next gate? - -## Decision Protocol - -For each substantive issue: - -- State the issue and evidence. -- Offer the smallest viable correction. -- Recommend one option and explain why. -- If the decision materially changes scope, ask or record the decision explicitly. -- If the fix is obvious and low-risk, state it and continue. - -Never silently default unresolved thesis decisions. List them in the final output -as unresolved decisions that may change downstream work. - -## Route Internally - -- `$market-opportunity` -- `$beachhead-segment` -- `$competitive-analysis-to-winning-positioning-strategy` -- `$product-assumptions-from-core-strategy-inputs` -- `$risky-assumption-prioritization-for-rapid-validation` -- `$pre-mortem` -- `$strategic-crux-diagnosis-and-strategy-design` - -## Required Output - -Return: - -1. **Thesis**: user, problem, wedge, position, price/value capture, and why now. -2. **Evidence Map**: facts, assumptions, missing evidence, and riskiest leap. -3. **Mode And Scope Decision**: expansion, selective expansion, hold, reduction, pause, or kill; include accepted/deferred/skipped changes. -4. **Challenge**: strongest reason this thesis may be wrong and the fastest way to learn. -5. **Risk Register**: assumptions, evidence, tests, thresholds, and owner. -6. **Decision**: proceed, narrow, validate, pivot, pause, or kill. -7. **Next Gate**: product, design, eng, QA, release, docs, DX, or comms gate if needed; flag stale gates. -8. **Completion Summary**: status, confidence, unresolved decisions, and what would change your mind. diff --git a/skills/thesis-review/agents/openai.yaml b/skills/thesis-review/agents/openai.yaml deleted file mode 100644 index 03511396..00000000 --- a/skills/thesis-review/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Thesis Review" - short_description: "Product thesis gate for new bets, capability scope, wedge, market, positioning, pricing, and kill-or-continue..." - brand_color: "#059669" - default_prompt: "Use $thesis-review with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/thesis-review/productize.json b/skills/thesis-review/productize.json deleted file mode 100644 index d5200d9d..00000000 --- a/skills/thesis-review/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Thesis Review", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "thesis-review", - "reviewer", - "gate", - "entry-point", - "product-thesis", - "wedge", - "positioning", - "pricing", - "kill-decision", - "thesis", - "review", - "new", - "bets", - "capability" - ], - "use_when": "Use Thesis Review before committing to a new product bet, capability scope, wedge, positioning, pricing, or growth direction when the team needs a clear proceed, narrow, validate, pivot, pause, or kill decision.", - "do_not_use_when": "Do not use Thesis Review for implementation details, visual polish, QA execution, release mechanics, or docs updates after the thesis is already settled. Route those to the specific Productize gate.", - "output_artifact": "Thesis review with product thesis, evidence map, challenge, decision, and next gate", - "routing_signals": [ - "thesis-review", - "product-thesis", - "wedge", - "positioning", - "pricing", - "kill-decision", - "new-bet", - "scope-capability", - "market-thesis", - "strategic-challenge", - "thesis", - "review", - "gate", - "new" - ], - "framework_fit": "Thesis Review fits the front of 0-1 and major growth pivots, where the product direction must be challenged before downstream design, engineering, QA, release, docs, or comms work creates momentum around the wrong bet.", - "failure_modes": [ - "Approves a thesis without naming the riskiest assumption, the missing evidence, and the specific next validation or narrowing decision.", - "Turns into generic strategy commentary instead of producing a crisp proceed, narrow, validate, pivot, pause, or kill gate decision.", - "Duplicates 0-1 Move 1 work without challenging the market, wedge, positioning, pricing, and evidence threshold as a gate." - ], - "examples": [ - { - "prompt": "Use $thesis-review to challenge this product thesis, wedge, positioning, and pricing before we commit a build team.", - "expected_artifact": "Thesis review with product thesis, evidence map, challenge, decision, and next gate" - } - ] -} diff --git a/skills/trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md b/skills/trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md deleted file mode 100644 index 35527ced..00000000 --- a/skills/trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -name: trade-off-analysis-from-feature-priority-and-effort-data -description: >- - Trade-off analysis from feature priority and effort data. Use when the user needs a product - workflow for stakeholder management related to trade-off analysis from feature priority and - effort data. Trigger terms: prioritization, tradeoffs, feature-evaluation. ---- - - - -# Trade-off analysis from feature priority and effort data - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `trade-off-analysis-from-feature-priority-and-effort-data` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Trade-off analysis from feature priority and effort data analytics diagnosis with metric readout, caveats, decision, and next instrumented step - -Use this skill to run the Productize prompt contract for **Trade-off analysis from feature priority and effort data**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{STAKEHOLDER_REQUEST}} -- {{FEATURE_PRIORITY}} -- {{FEATURE_EFFORT}} - - -GOAL -Produce a high-quality deliverable for: Trade-off analysis from feature priority and effort data. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{STAKEHOLDER_REQUEST}}` using `{{FEATURE_PRIORITY}}` and `{{FEATURE_EFFORT}}`. -- Identify key benefits, drawbacks/opportunity costs, and lower-effort alternatives addressing similar needs. -- Build a 2x2 priority-effort matrix with quadrants: -- High Priority / Low Effort -- High Priority / High Effort -- Low Priority / Low Effort -- Low Priority / High Effort -- Place the proposed feature in the correct quadrant and include 2-3 comparator features/initiatives across other quadrants. -- Provide concise explanation for each matrix item (benefits, drawbacks, and placement rationale). -- Recommend whether to pursue, defer, or reject, with concrete next steps and alternatives. - -FORMAT -Return exactly this structure: - - - -[Insert your 2x2 matrix here, using ASCII art or a simple text representation] - - - -[Provide brief explanations for each item in the matrix] - - - -[Offer your recommendation and next steps] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Matrix is missing the proposed feature or lacks 2-3 comparator items. -- Explanations do not justify quadrant placement with benefits/drawbacks. -- Recommendation is generic or does not provide clear next steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md.tmpl b/skills/trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md.tmpl deleted file mode 100644 index 4f32f679..00000000 --- a/skills/trade-off-analysis-from-feature-priority-and-effort-data/SKILL.md.tmpl +++ /dev/null @@ -1,76 +0,0 @@ ---- -name: trade-off-analysis-from-feature-priority-and-effort-data -description: >- - Trade-off analysis from feature priority and effort data. Use when the user needs a product - workflow for stakeholder management related to trade-off analysis from feature priority and - effort data. Trigger terms: prioritization, tradeoffs, feature-evaluation. ---- -# Trade-off analysis from feature priority and effort data - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Trade-off analysis from feature priority and effort data**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{STAKEHOLDER_REQUEST}} -- {{FEATURE_PRIORITY}} -- {{FEATURE_EFFORT}} - - -GOAL -Produce a high-quality deliverable for: Trade-off analysis from feature priority and effort data. -Success metric: -- Completes all required tasks and decision logic from the prompt instructions. -- Output is specific, evidence-based, and actionable. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required analysis steps, sections, or validation logic. -- Keep recommendations/outputs grounded in the input context; avoid generic filler. -- Analyze `{{STAKEHOLDER_REQUEST}}` using `{{FEATURE_PRIORITY}}` and `{{FEATURE_EFFORT}}`. -- Identify key benefits, drawbacks/opportunity costs, and lower-effort alternatives addressing similar needs. -- Build a 2x2 priority-effort matrix with quadrants: -- High Priority / Low Effort -- High Priority / High Effort -- Low Priority / Low Effort -- Low Priority / High Effort -- Place the proposed feature in the correct quadrant and include 2-3 comparator features/initiatives across other quadrants. -- Provide concise explanation for each matrix item (benefits, drawbacks, and placement rationale). -- Recommend whether to pursue, defer, or reject, with concrete next steps and alternatives. - -FORMAT -Return exactly this structure: - - - -[Insert your 2x2 matrix here, using ASCII art or a simple text representation] - - - -[Provide brief explanations for each item in the matrix] - - - -[Offer your recommendation and next steps] - - - -FAILURE -- Any required section in `` is missing or materially incomplete. -- Matrix is missing the proposed feature or lacks 2-3 comparator items. -- Explanations do not justify quadrant placement with benefits/drawbacks. -- Recommendation is generic or does not provide clear next steps. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/trade-off-analysis-from-feature-priority-and-effort-data/agents/openai.yaml b/skills/trade-off-analysis-from-feature-priority-and-effort-data/agents/openai.yaml deleted file mode 100644 index 3f59e545..00000000 --- a/skills/trade-off-analysis-from-feature-priority-and-effort-data/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Trade-off analysis from feature priority and effort data" - short_description: "Trade-off analysis from feature priority and effort data. Use when the user needs a product workflow for stakeholder..." - brand_color: "#0F766E" - default_prompt: "Use $trade-off-analysis-from-feature-priority-and-effort-data with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/trade-off-analysis-from-feature-priority-and-effort-data/productize.json b/skills/trade-off-analysis-from-feature-priority-and-effort-data/productize.json deleted file mode 100644 index 9ecdeb64..00000000 --- a/skills/trade-off-analysis-from-feature-priority-and-effort-data/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Trade-off analysis from feature priority and effort data", - "category": "Analytics", - "lifecycle": "Measure", - "tags": [ - "trade-off-analysis-from-feature-priority-and-effort-data", - "trade", - "off", - "feature", - "priority", - "effort", - "data" - ], - "use_when": "Trade-off analysis from feature priority and effort data. Use when the user needs a product workflow for stakeholder management related to trade-off analysis from feature priority and effort data. Trigger terms: prioritization, tradeoffs, feature-evaluation.", - "do_not_use_when": "Do not use Trade-off analysis from feature priority and effort data when the request is mainly early ideation, qualitative research, or roadmap writing without metrics; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Trade-off analysis from feature priority and effort data analytics diagnosis with metric readout, caveats, decision, and next instrumented step", - "routing_signals": [ - "trade-off-analysis-from-feature-priority-and-effort-data", - "trade", - "off", - "feature", - "priority", - "effort", - "data" - ], - "framework_fit": "Trade-off analysis from feature priority and effort data fits Analytics work in the Measure lifecycle when the user needs Trade-off analysis from feature priority and effort data analytics diagnosis with metric readout, caveats, decision, and next instrumented step and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Trade-off analysis from feature priority and effort data analytics diagnosis with metric readout, caveats, decision, and next instrumented step without tying recommendations to the user's Measure stage, evidence, and decision pressure.", - "Treats Trade-off analysis from feature priority and effort data as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Trade-off analysis from feature priority and effort data when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $trade-off-analysis-from-feature-priority-and-effort-data to turn this trade context into a decision-ready Trade-off analysis from feature priority and effort data analytics diagnosis with metric readout, caveats, decision, and next instrumented step.", - "expected_artifact": "Trade-off analysis from feature priority and effort data analytics diagnosis with metric readout, caveats, decision, and next instrumented step" - } - ] -} diff --git a/skills/user-stories-from-initiative-requirements/SKILL.md b/skills/user-stories-from-initiative-requirements/SKILL.md deleted file mode 100644 index 0f239fb6..00000000 --- a/skills/user-stories-from-initiative-requirements/SKILL.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -name: user-stories-from-initiative-requirements -description: >- - User stories from initiative requirements. Use when the user needs a product workflow for - business analysis related to user stories from initiative requirements. Trigger terms: pm, - user-stories, requirements, business-analysis. ---- - - - -# User stories from initiative requirements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `user-stories-from-initiative-requirements` -- **Lifecycle**: Design -- **Category**: Delivery -- **Primary artifact**: User stories from initiative requirements UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **User stories from initiative requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_STORY_TEMPLATE}} -- {{INITIATIVE_CONTEXT}} -- {{FUNCTIONALITY_DESCRIPTION}} - - -GOAL -Break initiative functionality into clear, implementable user stories using `USER_STORY_TEMPLATE`, `INITIATIVE_CONTEXT`, and `FUNCTIONALITY_DESCRIPTION`. -Success metric: -- Produces separate stories for distinct functionality/interaction units. -- Each story is self-contained, value-driven, and has testable acceptance criteria. -- Story wording follows the provided template structure. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required workflow: - 1. Read template, context, and functionality description. - 2. Decompose functionality into distinct user-value units. - 3. Draft one story per unit. - 4. Add clear, testable acceptance criteria per story. -- Follow `USER_STORY_TEMPLATE` exactly for each story. -- Keep stories implementation-ready, user-value focused, and non-duplicative. -- Ensure each story is atomic (single primary intent/outcome). -- Include a brief summary of decomposition logic and key considerations. - -FORMAT -Return exactly this structure: - -Here are the user stories for the described initiative: -1. [User story 1 using the provided template, including clear acceptance criteria] -2. [User story 2] -[Continue numbering for all required stories] -[Brief summary of decomposition approach and key considerations] - -FAILURE -- Missing required line header, missing numbered `` list, or missing ``. -- Stories do not follow the provided template structure. -- Stories are vague, not testable, or not grounded in provided context/functionality. -- Stories are duplicative or combine multiple primary intents into one. -- Assumptions are used but not explicitly stated. diff --git a/skills/user-stories-from-initiative-requirements/SKILL.md.tmpl b/skills/user-stories-from-initiative-requirements/SKILL.md.tmpl deleted file mode 100644 index a86ced96..00000000 --- a/skills/user-stories-from-initiative-requirements/SKILL.md.tmpl +++ /dev/null @@ -1,65 +0,0 @@ ---- -name: user-stories-from-initiative-requirements -description: >- - User stories from initiative requirements. Use when the user needs a product workflow for - business analysis related to user stories from initiative requirements. Trigger terms: pm, - user-stories, requirements, business-analysis. ---- -# User stories from initiative requirements - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **User stories from initiative requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{USER_STORY_TEMPLATE}} -- {{INITIATIVE_CONTEXT}} -- {{FUNCTIONALITY_DESCRIPTION}} - - -GOAL -Break initiative functionality into clear, implementable user stories using `USER_STORY_TEMPLATE`, `INITIATIVE_CONTEXT`, and `FUNCTIONALITY_DESCRIPTION`. -Success metric: -- Produces separate stories for distinct functionality/interaction units. -- Each story is self-contained, value-driven, and has testable acceptance criteria. -- Story wording follows the provided template structure. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required workflow: - 1. Read template, context, and functionality description. - 2. Decompose functionality into distinct user-value units. - 3. Draft one story per unit. - 4. Add clear, testable acceptance criteria per story. -- Follow `USER_STORY_TEMPLATE` exactly for each story. -- Keep stories implementation-ready, user-value focused, and non-duplicative. -- Ensure each story is atomic (single primary intent/outcome). -- Include a brief summary of decomposition logic and key considerations. - -FORMAT -Return exactly this structure: - -Here are the user stories for the described initiative: -1. [User story 1 using the provided template, including clear acceptance criteria] -2. [User story 2] -[Continue numbering for all required stories] -[Brief summary of decomposition approach and key considerations] - -FAILURE -- Missing required line header, missing numbered `` list, or missing ``. -- Stories do not follow the provided template structure. -- Stories are vague, not testable, or not grounded in provided context/functionality. -- Stories are duplicative or combine multiple primary intents into one. -- Assumptions are used but not explicitly stated. diff --git a/skills/user-stories-from-initiative-requirements/agents/openai.yaml b/skills/user-stories-from-initiative-requirements/agents/openai.yaml deleted file mode 100644 index 362d4d52..00000000 --- a/skills/user-stories-from-initiative-requirements/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "User stories from initiative requirements" - short_description: "User stories from initiative requirements. Use when the user needs a product workflow for business analysis related..." - brand_color: "#4F46E5" - default_prompt: "Use $user-stories-from-initiative-requirements with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/user-stories-from-initiative-requirements/productize.json b/skills/user-stories-from-initiative-requirements/productize.json deleted file mode 100644 index 99bed7e7..00000000 --- a/skills/user-stories-from-initiative-requirements/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "User stories from initiative requirements", - "category": "Delivery", - "lifecycle": "Design", - "tags": [ - "user-stories-from-initiative-requirements", - "stories", - "initiative", - "requirements", - "business", - "delivery" - ], - "use_when": "User stories from initiative requirements. Use when the user needs a product workflow for business analysis related to user stories from initiative requirements. Trigger terms: pm, user-stories, requirements, business-analysis.", - "do_not_use_when": "Do not use User stories from initiative requirements when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "User stories from initiative requirements UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "user-stories-from-initiative-requirements", - "stories", - "initiative", - "requirements", - "business", - "delivery" - ], - "framework_fit": "User stories from initiative requirements fits Delivery work in the Design lifecycle when the user needs User stories from initiative requirements UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces User stories from initiative requirements UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats User stories from initiative requirements as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from User stories from initiative requirements when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $user-stories-from-initiative-requirements to turn this stories context into a decision-ready User stories from initiative requirements UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "User stories from initiative requirements UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md b/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md deleted file mode 100644 index 292b55da..00000000 --- a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -name: user-stories-with-gherkin-acceptance-criteria-from-requirements -description: >- - User stories with Gherkin acceptance criteria from requirements. Use when the user needs a - product workflow for business analysis related to user stories with gherkin acceptance - criteria from requirements. Trigger terms: pm, user-stories, gherkin, requirements, - business-analysis. ---- - - - -# User stories with Gherkin acceptance criteria from requirements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `user-stories-with-gherkin-acceptance-criteria-from-requirements` -- **Lifecycle**: Design -- **Category**: Delivery -- **Primary artifact**: User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **User stories with Gherkin acceptance criteria from requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Generate INVEST-compliant, atomic user stories with Gherkin acceptance criteria from provided requirements context. -Success metric: -- Produces one or more atomic user stories aligned to persona goals and constraints. -- Each story includes deterministic happy-path and edge/negative Gherkin scenarios. -- Includes traceability from requirements to stories and acceptance criteria. -- Follows the required markdown output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required steps: - 1. Decompose requirements into distinct atomic outcomes. - 2. Draft one story per outcome. - 3. Add Gherkin acceptance criteria with one `When` and one `Then` in happy path. - 4. Add at least one edge/negative scenario per story. - 5. Complete notes and traceability mapping. -- Stories must be INVEST-compliant and persona-aligned. -- If a story would require multiple primary outcomes, split it or mark `SPLIT SUGGESTED`. -- Keep language testable and implementation-neutral (unless a technical constraint is explicitly required). -- Use `[TBD]` for critical missing info and surface it under Open Questions. - -FORMAT -Return exactly this structure: - -```md -Backlog Context -[Backlog Header Template fields filled] - -User Story [ID-###]: -[Use Case + Gherkin happy-path scenario + Gherkin edge/negative scenario] -Notes -[Non-Functional, Instrumentation, Dependencies, Out of Scope, Open Questions] - -[Repeat story blocks for each atomic outcome] - -Traceability Table -[Requirement ID | Requirement Summary | Story ID(s) | AC Coverage Notes] - -Validation Checklist -[All required checklist items] -``` - -FAILURE -- Required markdown structure is missing or malformed. -- Stories are non-atomic, non-INVEST, or not mapped to clear outcomes. -- Happy-path scenario contains more than one `When` or more than one `Then` without `SPLIT SUGGESTED`. -- Edge/negative scenario is missing for any story. -- Traceability table or validation checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `3 cs`, `invest`, `user stories`, `conversation confirmation`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md.tmpl b/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md.tmpl deleted file mode 100644 index 5d0d02c0..00000000 --- a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/SKILL.md.tmpl +++ /dev/null @@ -1,83 +0,0 @@ ---- -name: user-stories-with-gherkin-acceptance-criteria-from-requirements -description: >- - User stories with Gherkin acceptance criteria from requirements. Use when the user needs a - product workflow for business analysis related to user stories with gherkin acceptance - criteria from requirements. Trigger terms: pm, user-stories, gherkin, requirements, - business-analysis. ---- -# User stories with Gherkin acceptance criteria from requirements - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **User stories with Gherkin acceptance criteria from requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- [No explicit variables declared; use provided context.] - - -GOAL -Generate INVEST-compliant, atomic user stories with Gherkin acceptance criteria from provided requirements context. -Success metric: -- Produces one or more atomic user stories aligned to persona goals and constraints. -- Each story includes deterministic happy-path and edge/negative Gherkin scenarios. -- Includes traceability from requirements to stories and acceptance criteria. -- Follows the required markdown output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip required steps: - 1. Decompose requirements into distinct atomic outcomes. - 2. Draft one story per outcome. - 3. Add Gherkin acceptance criteria with one `When` and one `Then` in happy path. - 4. Add at least one edge/negative scenario per story. - 5. Complete notes and traceability mapping. -- Stories must be INVEST-compliant and persona-aligned. -- If a story would require multiple primary outcomes, split it or mark `SPLIT SUGGESTED`. -- Keep language testable and implementation-neutral (unless a technical constraint is explicitly required). -- Use `[TBD]` for critical missing info and surface it under Open Questions. - -FORMAT -Return exactly this structure: - -```md -Backlog Context -[Backlog Header Template fields filled] - -User Story [ID-###]: -[Use Case + Gherkin happy-path scenario + Gherkin edge/negative scenario] -Notes -[Non-Functional, Instrumentation, Dependencies, Out of Scope, Open Questions] - -[Repeat story blocks for each atomic outcome] - -Traceability Table -[Requirement ID | Requirement Summary | Story ID(s) | AC Coverage Notes] - -Validation Checklist -[All required checklist items] -``` - -FAILURE -- Required markdown structure is missing or malformed. -- Stories are non-atomic, non-INVEST, or not mapped to clear outcomes. -- Happy-path scenario contains more than one `When` or more than one `Then` without `SPLIT SUGGESTED`. -- Edge/negative scenario is missing for any story. -- Traceability table or validation checklist is missing. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `3 cs`, `invest`, `user stories`, `conversation confirmation`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. diff --git a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/agents/openai.yaml b/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/agents/openai.yaml deleted file mode 100644 index dbc33772..00000000 --- a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "User stories with Gherkin acceptance criteria from requirements" - short_description: "User stories with Gherkin acceptance criteria from requirements. Use when the user needs a product workflow for..." - brand_color: "#4F46E5" - default_prompt: "Use $user-stories-with-gherkin-acceptance-criteria-from-requirements with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/productize.json b/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/productize.json deleted file mode 100644 index 4a87ab9d..00000000 --- a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/productize.json +++ /dev/null @@ -1,47 +0,0 @@ -{ - "title": "User stories with Gherkin acceptance criteria from requirements", - "category": "Delivery", - "lifecycle": "Design", - "tags": [ - "user-stories-with-gherkin-acceptance-criteria-from-requirements", - "stories", - "gherkin", - "acceptance", - "criteria", - "requirements", - "3-cs", - "invest", - "user-stories", - "conversation-confirmation" - ], - "use_when": "User stories with Gherkin acceptance criteria from requirements. Use when the user needs a product workflow for business analysis related to user stories with gherkin acceptance criteria from requirements. Trigger terms: pm, user-stories, gherkin, requirements, business-analysis.", - "do_not_use_when": "Do not use User stories with Gherkin acceptance criteria from requirements when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "user-stories-with-gherkin-acceptance-criteria-from-requirements", - "stories", - "gherkin", - "acceptance", - "criteria", - "requirements", - "3-cs", - "invest", - "user-stories", - "conversation-confirmation" - ], - "framework_fit": "User stories with Gherkin acceptance criteria from requirements fits Delivery work in the Design lifecycle when the user needs User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats User stories with Gherkin acceptance criteria from requirements as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from User stories with Gherkin acceptance criteria from requirements when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $user-stories-with-gherkin-acceptance-criteria-from-requirements to turn this stories context into a decision-ready User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "User stories with Gherkin acceptance criteria from requirements UX/design review with findings, constraints, fixes, and acceptance checks" - } - ], - "references": [ - "references/pm-skills-main-merge.md" - ] -} diff --git a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/references/pm-skills-main-merge.md b/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/references/pm-skills-main-merge.md deleted file mode 100644 index 18b92c9c..00000000 --- a/skills/user-stories-with-gherkin-acceptance-criteria-from-requirements/references/pm-skills-main-merge.md +++ /dev/null @@ -1,81 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to improve story quality with 3 Cs, INVEST checks, conversation notes, design links, and acceptance criteria. - -## Routing Signals - -- 3 cs -- invest -- user stories -- conversation confirmation - -## pm-execution/skills/user-stories/SKILL.md - -Create user stories following the 3 C's (Card, Conversation, Confirmation) and INVEST criteria. Generates stories with descriptions, design links, and acceptance criteria. - -**Use when:** Writing user stories, breaking down features into stories, creating backlog items, or defining acceptance criteria. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$FEATURE`: The new feature to break into stories -- `$DESIGN`: Link to design files (Figma, Miro, etc.) -- `$ASSUMPTIONS`: Key assumptions or context - -## Step-by-Step Process - -1. **Analyze the feature** based on provided design and context -2. **Identify user roles** and distinct user journeys -3. **Apply 3 C's framework:** - - Card: Simple title and one-liner - - Conversation: Detailed discussion of intent - - Confirmation: Clear acceptance criteria -4. **Respect INVEST criteria:** Independent, Negotiable, Valuable, Estimable, Small, Testable -5. **Use plain language** a primary school graduate can understand -6. **Link to design files** for visual reference -7. **Output user stories** in structured format - -## Story Template - -**Title:** [Feature name] - -**Description:** As a [user role], I want to [action], so that [benefit]. - -**Design:** [Link to design files] - -**Acceptance Criteria:** -1. [Clear, testable criterion] -2. [Observable behavior] -3. [System validates correctly] -4. [Edge case handling] -5. [Performance or accessibility consideration] -6. [Integration point] - -## Example User Story - -**Title:** Recently Viewed Section - -**Description:** As an Online Shopper, I want to see a 'Recently viewed' section on the product page to easily revisit items I considered. - -**Design:** [Figma link] - -**Acceptance Criteria:** -1. The 'Recently viewed' section is displayed at the bottom of the product page for every user who has previously viewed at least 1 product. -2. It is not displayed for users visiting the first product page of their session. -3. The current product itself is excluded from the displayed items. -4. The section showcases product cards or thumbnails with images, titles, and prices. -5. Each product card indicates when it was viewed (e.g., 'Viewed 5 minutes ago'). -6. Clicking on a product card leads the user to the corresponding product page. - -## Output Deliverables - -- Complete set of user stories for the feature -- Each story includes title, description, design link, and 4-6 acceptance criteria -- Stories are independent and can be developed in any order -- Stories are sized for one sprint cycle -- Stories reference related design documentation - ---- - -### Further Reading - -- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories) diff --git a/skills/ux-edge-cases-from-product-briefs/SKILL.md b/skills/ux-edge-cases-from-product-briefs/SKILL.md deleted file mode 100644 index 48fa3f6e..00000000 --- a/skills/ux-edge-cases-from-product-briefs/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: ux-edge-cases-from-product-briefs -description: >- - UX edge cases from product briefs. Use when the user needs a product workflow for business - analysis related to ux edge cases from product briefs. Trigger terms: pm, ux, design, - edge-cases, business-analysis. ---- - - - -# UX edge cases from product briefs - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ux-edge-cases-from-product-briefs` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: UX edge cases from product briefs UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **UX edge cases from product briefs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_BRIEF}} - - -GOAL -Identify UX edge cases from `PRODUCT_BRIEF` and define expected behavior for each scenario. -Success metric: -- Produces a comprehensive scenario set (target 15-20 unique scenarios). -- Covers diverse user types, contexts, failures, accessibility, and security/privacy considerations. -- Defines clear, testable expected behavior per scenario. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip scenario classes: - - user-type differences, - - context/device variations, - - error/misuse flows, - - system/network failures, - - integrations/dependencies, - - performance/load behavior, - - security/privacy edge cases, - - accessibility interactions. -- Keep each scenario concrete and distinct (avoid duplicates). -- Define expected behavior in product terms (clear response, recovery path, and user feedback when relevant). -- If the brief is missing specifics, state assumptions explicitly. - -FORMAT -Return exactly this structure: - - -Based on the product brief, here are the potential scenarios and their expected behaviors: - -| Scenario | Expected Behavior | -|----------|-------------------| -| [Scenario 1] | [Expected Behavior 1] | -| [Scenario 2] | [Expected Behavior 2] | -| ... | ... | -| [Scenario n] | [Expected Behavior n] | - - - -FAILURE -- Required schema is missing or malformed. -- Fewer than 15 scenarios unless explicitly constrained by provided brief. -- Scenario coverage is narrow (missing key classes like accessibility, failures, or security/privacy). -- Expected behaviors are vague, non-testable, or not tied to scenario conditions. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/ux-edge-cases-from-product-briefs/SKILL.md.tmpl b/skills/ux-edge-cases-from-product-briefs/SKILL.md.tmpl deleted file mode 100644 index aa7319b1..00000000 --- a/skills/ux-edge-cases-from-product-briefs/SKILL.md.tmpl +++ /dev/null @@ -1,73 +0,0 @@ ---- -name: ux-edge-cases-from-product-briefs -description: >- - UX edge cases from product briefs. Use when the user needs a product workflow for business - analysis related to ux edge cases from product briefs. Trigger terms: pm, ux, design, - edge-cases, business-analysis. ---- -# UX edge cases from product briefs - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **UX edge cases from product briefs**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_BRIEF}} - - -GOAL -Identify UX edge cases from `PRODUCT_BRIEF` and define expected behavior for each scenario. -Success metric: -- Produces a comprehensive scenario set (target 15-20 unique scenarios). -- Covers diverse user types, contexts, failures, accessibility, and security/privacy considerations. -- Defines clear, testable expected behavior per scenario. -- Follows the required output structure exactly. - -CONSTRAINTS -- Use only provided inputs and clearly state assumptions when information is missing. -- Do not skip scenario classes: - - user-type differences, - - context/device variations, - - error/misuse flows, - - system/network failures, - - integrations/dependencies, - - performance/load behavior, - - security/privacy edge cases, - - accessibility interactions. -- Keep each scenario concrete and distinct (avoid duplicates). -- Define expected behavior in product terms (clear response, recovery path, and user feedback when relevant). -- If the brief is missing specifics, state assumptions explicitly. - -FORMAT -Return exactly this structure: - - -Based on the product brief, here are the potential scenarios and their expected behaviors: - -| Scenario | Expected Behavior | -|----------|-------------------| -| [Scenario 1] | [Expected Behavior 1] | -| [Scenario 2] | [Expected Behavior 2] | -| ... | ... | -| [Scenario n] | [Expected Behavior n] | - - - -FAILURE -- Required schema is missing or malformed. -- Fewer than 15 scenarios unless explicitly constrained by provided brief. -- Scenario coverage is narrow (missing key classes like accessibility, failures, or security/privacy). -- Expected behaviors are vague, non-testable, or not tied to scenario conditions. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/ux-edge-cases-from-product-briefs/agents/openai.yaml b/skills/ux-edge-cases-from-product-briefs/agents/openai.yaml deleted file mode 100644 index 31de4618..00000000 --- a/skills/ux-edge-cases-from-product-briefs/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "UX edge cases from product briefs" - short_description: "UX edge cases from product briefs. Use when the user needs a product workflow for business analysis related to ux..." - brand_color: "#DB2777" - default_prompt: "Use $ux-edge-cases-from-product-briefs with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/ux-edge-cases-from-product-briefs/productize.json b/skills/ux-edge-cases-from-product-briefs/productize.json deleted file mode 100644 index 1cdfde06..00000000 --- a/skills/ux-edge-cases-from-product-briefs/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "UX edge cases from product briefs", - "category": "Design", - "lifecycle": "Design", - "tags": [ - "ux-edge-cases-from-product-briefs", - "edge", - "cases", - "briefs", - "business", - "design" - ], - "use_when": "UX edge cases from product briefs. Use when the user needs a product workflow for business analysis related to ux edge cases from product briefs. Trigger terms: pm, ux, design, edge-cases, business-analysis.", - "do_not_use_when": "Do not use UX edge cases from product briefs when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "UX edge cases from product briefs UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "ux-edge-cases-from-product-briefs", - "edge", - "cases", - "briefs", - "business", - "design" - ], - "framework_fit": "UX edge cases from product briefs fits Design work in the Design lifecycle when the user needs UX edge cases from product briefs UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces UX edge cases from product briefs UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats UX edge cases from product briefs as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from UX edge cases from product briefs when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $ux-edge-cases-from-product-briefs to turn this edge context into a decision-ready UX edge cases from product briefs UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "UX edge cases from product briefs UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/ux-terminology-improvements-in-product-requirements/SKILL.md b/skills/ux-terminology-improvements-in-product-requirements/SKILL.md deleted file mode 100644 index c7d8b525..00000000 --- a/skills/ux-terminology-improvements-in-product-requirements/SKILL.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -name: ux-terminology-improvements-in-product-requirements -description: >- - UX terminology improvements in product requirements. Use when the user needs a product - workflow for design & prototyping related to ux terminology improvements in product - requirements. Trigger terms: ux, product-requirements, terminology, content-review. ---- - - - -# UX terminology improvements in product requirements - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `ux-terminology-improvements-in-product-requirements` -- **Lifecycle**: Design -- **Category**: Design -- **Primary artifact**: UX terminology improvements in product requirements UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **UX terminology improvements in product requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_MANAGER_REQUIREMENTS}} - - -GOAL -Produce a high-quality deliverable for: "UX terminology improvements in product requirements". -Success metric: -- Identifies incorrect or imprecise UX terminology in the requirements, when present. -- Provides context-appropriate terminology corrections with clear rationale. -- Avoids unnecessary edits when wording is already accurate. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_MANAGER_REQUIREMENTS}}`; if context is missing, state assumptions explicitly. -- Review terms in context; do not auto-replace words without justification. -- For each correction, quote the original wording exactly. -- Provide a correction only when it improves UX precision/clarity. -- If no corrections are needed, explicitly return the no-change statement in the required schema. - -FORMAT -Return exactly this structure: - - -1. Original term: [Quote the original text] - Correction: [Provide the corrected term or phrase] - Explanation: [Briefly explain why this correction is necessary] - -2. Original term: [Quote the original text] - Correction: [Provide the corrected term or phrase] - Explanation: [Briefly explain why this correction is necessary] - -[Continue with additional corrections as needed] - -[If no corrections are required, return exactly: -"No corrections needed. The requirements use appropriate UX terminology."] - - -FAILURE -- `` section is missing or malformed. -- Corrections are provided without quoting original text. -- Explanations do not justify why the correction improves UX terminology precision. -- Output changes terminology that is already context-appropriate without rationale. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/ux-terminology-improvements-in-product-requirements/SKILL.md.tmpl b/skills/ux-terminology-improvements-in-product-requirements/SKILL.md.tmpl deleted file mode 100644 index 3fee6d22..00000000 --- a/skills/ux-terminology-improvements-in-product-requirements/SKILL.md.tmpl +++ /dev/null @@ -1,68 +0,0 @@ ---- -name: ux-terminology-improvements-in-product-requirements -description: >- - UX terminology improvements in product requirements. Use when the user needs a product - workflow for design & prototyping related to ux terminology improvements in product - requirements. Trigger terms: ux, product-requirements, terminology, content-review. ---- -# UX terminology improvements in product requirements - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **UX terminology improvements in product requirements**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT_MANAGER_REQUIREMENTS}} - - -GOAL -Produce a high-quality deliverable for: "UX terminology improvements in product requirements". -Success metric: -- Identifies incorrect or imprecise UX terminology in the requirements, when present. -- Provides context-appropriate terminology corrections with clear rationale. -- Avoids unnecessary edits when wording is already accurate. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT_MANAGER_REQUIREMENTS}}`; if context is missing, state assumptions explicitly. -- Review terms in context; do not auto-replace words without justification. -- For each correction, quote the original wording exactly. -- Provide a correction only when it improves UX precision/clarity. -- If no corrections are needed, explicitly return the no-change statement in the required schema. - -FORMAT -Return exactly this structure: - - -1. Original term: [Quote the original text] - Correction: [Provide the corrected term or phrase] - Explanation: [Briefly explain why this correction is necessary] - -2. Original term: [Quote the original text] - Correction: [Provide the corrected term or phrase] - Explanation: [Briefly explain why this correction is necessary] - -[Continue with additional corrections as needed] - -[If no corrections are required, return exactly: -"No corrections needed. The requirements use appropriate UX terminology."] - - -FAILURE -- `` section is missing or malformed. -- Corrections are provided without quoting original text. -- Explanations do not justify why the correction improves UX terminology precision. -- Output changes terminology that is already context-appropriate without rationale. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/ux-terminology-improvements-in-product-requirements/agents/openai.yaml b/skills/ux-terminology-improvements-in-product-requirements/agents/openai.yaml deleted file mode 100644 index 81f26675..00000000 --- a/skills/ux-terminology-improvements-in-product-requirements/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "UX terminology improvements in product requirements" - short_description: "UX terminology improvements in product requirements. Use when the user needs a product workflow for design &..." - brand_color: "#DB2777" - default_prompt: "Use $ux-terminology-improvements-in-product-requirements with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/ux-terminology-improvements-in-product-requirements/productize.json b/skills/ux-terminology-improvements-in-product-requirements/productize.json deleted file mode 100644 index d4cef91b..00000000 --- a/skills/ux-terminology-improvements-in-product-requirements/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "UX terminology improvements in product requirements", - "category": "Design", - "lifecycle": "Design", - "tags": [ - "ux-terminology-improvements-in-product-requirements", - "terminology", - "improvements", - "requirements", - "design", - "prototyping" - ], - "use_when": "UX terminology improvements in product requirements. Use when the user needs a product workflow for design & prototyping related to ux terminology improvements in product requirements. Trigger terms: ux, product-requirements, terminology, content-review.", - "do_not_use_when": "Do not use UX terminology improvements in product requirements when the request is mainly metric diagnosis, pricing, GTM, or implementation planning without UX evidence; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "UX terminology improvements in product requirements UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "ux-terminology-improvements-in-product-requirements", - "terminology", - "improvements", - "requirements", - "design", - "prototyping" - ], - "framework_fit": "UX terminology improvements in product requirements fits Design work in the Design lifecycle when the user needs UX terminology improvements in product requirements UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces UX terminology improvements in product requirements UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats UX terminology improvements in product requirements as generic Design advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from UX terminology improvements in product requirements when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $ux-terminology-improvements-in-product-requirements to turn this terminology context into a decision-ready UX terminology improvements in product requirements UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "UX terminology improvements in product requirements UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/validate-data/SKILL.md b/skills/validate-data/SKILL.md deleted file mode 100644 index 615da0d8..00000000 --- a/skills/validate-data/SKILL.md +++ /dev/null @@ -1,267 +0,0 @@ ---- -name: validate-data -description: >- - QA an analysis before sharing, including methodology, accuracy, calculation, visualization, and - bias checks. Use when reviewing analysis for stakeholders, spot-checking SQL results, - validating aggregation logic, or assessing whether conclusions are supported by the data. ---- - - - -# Validate Data - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `validate-data` -- **Lifecycle**: Measure -- **Category**: Analytics -- **Primary artifact**: Data validation report with quality issues, methodology checks, and confidence level - -Review an analysis for accuracy, methodology, and potential bias before it is shared with stakeholders. - -## Argument Hint - -`` - -## Usage - -```text -/validate-data -``` - -The analysis can be a document, report, file, SQL query and results, chart, dataset, notebook, spreadsheet, or methodology summary. - -## Workflow - -### 1. Review Methodology and Assumptions - -Check: -- Question framing: whether the analysis answers the right question. -- Data selection: source tables, files, date ranges, and inclusion criteria. -- Population definition: who or what is included and excluded. -- Metric definitions: whether definitions are explicit and stakeholder-compatible. -- Baseline and comparison: whether comparison periods, cohorts, and contexts are fair. -- Assumptions: whether assumptions are stated and defensible. - -### 2. Run Pre-Delivery QA - -Review data quality: -- Sources are correct. -- Data freshness and "as of" date are stated. -- Time series and segments are complete. -- Null handling is appropriate. -- Deduplication and filters are correct. - -Review calculations: -- Aggregation grain matches the analysis question. -- Denominators are correct and non-zero. -- Date comparisons use equal and complete periods unless caveated. -- Join types are intentional. -- Many-to-many joins are not inflating counts. -- Metrics match stakeholder definitions. -- Subtotals reconcile with totals where expected. - -Review reasonableness: -- Numbers are plausible. -- Percentages are between 0 and 100 when applicable. -- Trends do not have unexplained jumps. -- Results reconcile with dashboards, finance reports, or prior analyses when possible. -- Boundary cases are sensible. - -Review presentation: -- Charts use honest axes and consistent scales. -- Titles, labels, date ranges, and units are clear. -- Number formatting is appropriate. -- Caveats are explicit. -- The analysis is reproducible. - -### 3. Check Analytical Pitfalls - -Look specifically for: -- Join explosion from many-to-many joins. -- Survivorship bias. -- Partial-period comparisons. -- Denominator shifting. -- Average of averages. -- Timezone mismatches. -- Selection bias in segmentation. -- Simpson's paradox. -- Correlation presented as causation. -- Small sample overclaiming. -- Outlier-distorted averages. -- Multiple testing and cherry-picking. -- Look-ahead bias. -- Cherry-picked time ranges. - -### 4. Verify Calculations - -Where possible: -- Recalculate key numbers independently. -- Check row counts before and after joins. -- Confirm subtotals and percentages. -- Verify YoY, MoM, and WoW base periods. -- Check that filters are applied consistently. -- Spot-check individual records or small slices. -- Calculate the same metric two ways when feasible. - -For SQL, inspect grain, joins, filters, grouping, denominator logic, and null handling. Use `sql-queries` for dialect-specific review when needed. - -### 5. Assess Visualizations - -If charts are included, verify: -- Bar charts start at zero. -- Scales are consistent across comparison panels. -- Titles accurately describe what is shown. -- Axes, units, date ranges, and sources are visible. -- Visual encodings do not mislead fast readers. -- No 3D effects, unexplained truncation, or inconsistent intervals. - -Use `data-visualization` if chart-design guidance is needed. - -### 6. Evaluate Narrative and Conclusions - -Review whether: -- Conclusions are directly supported by the data. -- Alternative explanations are acknowledged. -- Uncertainty is communicated. -- Recommendations follow from findings. -- Confidence level matches evidence strength. -- Practical significance is separated from statistical significance. - -Use `statistical-analysis` for significance, outlier, anomaly, correlation, or sample-size concerns. - -### 7. Produce Confidence Assessment - -Choose one: -- **Ready to share**: sound methodology, verified calculations, caveats noted. -- **Share with noted caveats**: largely correct, but limitations must be communicated. -- **Needs revision**: errors, methodological issues, or missing analyses should be fixed first. - -## Output Format - -```markdown -## Validation Report - -### Overall Assessment: [Ready to share | Share with caveats | Needs revision] - -### Methodology Review -[Findings about approach, data selection, definitions, comparison logic, and assumptions] - -### Issues Found -1. [Severity: High/Medium/Low] [Issue description, evidence, and impact] - -### Calculation Spot-Checks -- [Metric]: [Verified / Discrepancy found / Could not verify] - [notes] - -### Visualization Review -[Chart issues or confirmation that visuals are sound] - -### Suggested Improvements -1. [Improvement and why it matters] - -### Required Caveats for Stakeholders -- [Caveat that must be communicated] -``` - -## Pitfall Reference - -### Join Explosion - -Many-to-many joins silently multiply rows and inflate counts or sums. Check row counts before and after joins, investigate unexpected increases, and use `COUNT(DISTINCT entity_id)` when counting entities through joins. - -### Survivorship Bias - -Analyzing only current or surviving entities ignores churned, deleted, failed, or excluded entities. Ask who is missing from the dataset. - -### Incomplete Period Comparison - -Do not compare a partial week, month, or quarter to a full prior period unless explicitly caveated. Use complete periods or same-number-of-days comparisons. - -### Denominator Shifting - -Rate changes are not comparable if the eligible population or active-user definition changed between periods. - -### Average of Averages - -Never average pre-computed averages when group sizes differ. Recompute from raw numerators and denominators or use weighted averages. - -### Timezone Mismatches - -Standardize timestamps before comparison and document the timezone used. - -### Selection Bias - -Do not define segments using the outcome being measured. Prefer pre-treatment characteristics. - -## Red Flags - -Investigate: -- Metrics changing more than 50 percent without an obvious cause. -- Exact round-number counts or sums. -- Rates exactly 0 percent or 100 percent. -- Results that perfectly confirm the hypothesis. -- Identical values across periods or segments. -- Percentages that should sum to 100 percent but do not. - -## Reproducibility Standard - -For non-trivial analyses, ensure the report includes: -- Specific question. -- Data sources and "as of" dates. -- Metric and segment definitions. -- Time period and timezone. -- Methodology. -- Assumptions and limitations. -- Queries or code. -- Caveats and known gaps. diff --git a/skills/validate-data/SKILL.md.tmpl b/skills/validate-data/SKILL.md.tmpl deleted file mode 100644 index 1a8d186d..00000000 --- a/skills/validate-data/SKILL.md.tmpl +++ /dev/null @@ -1,208 +0,0 @@ ---- -name: validate-data -description: >- - QA an analysis before sharing, including methodology, accuracy, calculation, visualization, and - bias checks. Use when reviewing analysis for stakeholders, spot-checking SQL results, - validating aggregation logic, or assessing whether conclusions are supported by the data. ---- -# Validate Data - -{{PRODUCTIZE_PREAMBLE}} - -Review an analysis for accuracy, methodology, and potential bias before it is shared with stakeholders. - -## Argument Hint - -`` - -## Usage - -```text -/validate-data -``` - -The analysis can be a document, report, file, SQL query and results, chart, dataset, notebook, spreadsheet, or methodology summary. - -## Workflow - -### 1. Review Methodology and Assumptions - -Check: -- Question framing: whether the analysis answers the right question. -- Data selection: source tables, files, date ranges, and inclusion criteria. -- Population definition: who or what is included and excluded. -- Metric definitions: whether definitions are explicit and stakeholder-compatible. -- Baseline and comparison: whether comparison periods, cohorts, and contexts are fair. -- Assumptions: whether assumptions are stated and defensible. - -### 2. Run Pre-Delivery QA - -Review data quality: -- Sources are correct. -- Data freshness and "as of" date are stated. -- Time series and segments are complete. -- Null handling is appropriate. -- Deduplication and filters are correct. - -Review calculations: -- Aggregation grain matches the analysis question. -- Denominators are correct and non-zero. -- Date comparisons use equal and complete periods unless caveated. -- Join types are intentional. -- Many-to-many joins are not inflating counts. -- Metrics match stakeholder definitions. -- Subtotals reconcile with totals where expected. - -Review reasonableness: -- Numbers are plausible. -- Percentages are between 0 and 100 when applicable. -- Trends do not have unexplained jumps. -- Results reconcile with dashboards, finance reports, or prior analyses when possible. -- Boundary cases are sensible. - -Review presentation: -- Charts use honest axes and consistent scales. -- Titles, labels, date ranges, and units are clear. -- Number formatting is appropriate. -- Caveats are explicit. -- The analysis is reproducible. - -### 3. Check Analytical Pitfalls - -Look specifically for: -- Join explosion from many-to-many joins. -- Survivorship bias. -- Partial-period comparisons. -- Denominator shifting. -- Average of averages. -- Timezone mismatches. -- Selection bias in segmentation. -- Simpson's paradox. -- Correlation presented as causation. -- Small sample overclaiming. -- Outlier-distorted averages. -- Multiple testing and cherry-picking. -- Look-ahead bias. -- Cherry-picked time ranges. - -### 4. Verify Calculations - -Where possible: -- Recalculate key numbers independently. -- Check row counts before and after joins. -- Confirm subtotals and percentages. -- Verify YoY, MoM, and WoW base periods. -- Check that filters are applied consistently. -- Spot-check individual records or small slices. -- Calculate the same metric two ways when feasible. - -For SQL, inspect grain, joins, filters, grouping, denominator logic, and null handling. Use `sql-queries` for dialect-specific review when needed. - -### 5. Assess Visualizations - -If charts are included, verify: -- Bar charts start at zero. -- Scales are consistent across comparison panels. -- Titles accurately describe what is shown. -- Axes, units, date ranges, and sources are visible. -- Visual encodings do not mislead fast readers. -- No 3D effects, unexplained truncation, or inconsistent intervals. - -Use `data-visualization` if chart-design guidance is needed. - -### 6. Evaluate Narrative and Conclusions - -Review whether: -- Conclusions are directly supported by the data. -- Alternative explanations are acknowledged. -- Uncertainty is communicated. -- Recommendations follow from findings. -- Confidence level matches evidence strength. -- Practical significance is separated from statistical significance. - -Use `statistical-analysis` for significance, outlier, anomaly, correlation, or sample-size concerns. - -### 7. Produce Confidence Assessment - -Choose one: -- **Ready to share**: sound methodology, verified calculations, caveats noted. -- **Share with noted caveats**: largely correct, but limitations must be communicated. -- **Needs revision**: errors, methodological issues, or missing analyses should be fixed first. - -## Output Format - -```markdown -## Validation Report - -### Overall Assessment: [Ready to share | Share with caveats | Needs revision] - -### Methodology Review -[Findings about approach, data selection, definitions, comparison logic, and assumptions] - -### Issues Found -1. [Severity: High/Medium/Low] [Issue description, evidence, and impact] - -### Calculation Spot-Checks -- [Metric]: [Verified / Discrepancy found / Could not verify] - [notes] - -### Visualization Review -[Chart issues or confirmation that visuals are sound] - -### Suggested Improvements -1. [Improvement and why it matters] - -### Required Caveats for Stakeholders -- [Caveat that must be communicated] -``` - -## Pitfall Reference - -### Join Explosion - -Many-to-many joins silently multiply rows and inflate counts or sums. Check row counts before and after joins, investigate unexpected increases, and use `COUNT(DISTINCT entity_id)` when counting entities through joins. - -### Survivorship Bias - -Analyzing only current or surviving entities ignores churned, deleted, failed, or excluded entities. Ask who is missing from the dataset. - -### Incomplete Period Comparison - -Do not compare a partial week, month, or quarter to a full prior period unless explicitly caveated. Use complete periods or same-number-of-days comparisons. - -### Denominator Shifting - -Rate changes are not comparable if the eligible population or active-user definition changed between periods. - -### Average of Averages - -Never average pre-computed averages when group sizes differ. Recompute from raw numerators and denominators or use weighted averages. - -### Timezone Mismatches - -Standardize timestamps before comparison and document the timezone used. - -### Selection Bias - -Do not define segments using the outcome being measured. Prefer pre-treatment characteristics. - -## Red Flags - -Investigate: -- Metrics changing more than 50 percent without an obvious cause. -- Exact round-number counts or sums. -- Rates exactly 0 percent or 100 percent. -- Results that perfectly confirm the hypothesis. -- Identical values across periods or segments. -- Percentages that should sum to 100 percent but do not. - -## Reproducibility Standard - -For non-trivial analyses, ensure the report includes: -- Specific question. -- Data sources and "as of" dates. -- Metric and segment definitions. -- Time period and timezone. -- Methodology. -- Assumptions and limitations. -- Queries or code. -- Caveats and known gaps. diff --git a/skills/validate-data/agents/openai.yaml b/skills/validate-data/agents/openai.yaml deleted file mode 100644 index 2bc2190a..00000000 --- a/skills/validate-data/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Validate Data" - short_description: "QA an analysis before sharing, including methodology, accuracy, calculation, visualization, and bias checks. Use..." - brand_color: "#0F766E" - default_prompt: "Use $validate-data with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/validate-data/productize.json b/skills/validate-data/productize.json deleted file mode 100644 index 8d753e2b..00000000 --- a/skills/validate-data/productize.json +++ /dev/null @@ -1,48 +0,0 @@ -{ - "title": "Validate Data", - "category": "Analytics", - "tags": [ - "data-validation", - "analysis-review", - "qa", - "methodology", - "bias-check", - "stakeholder-readiness", - "validate-data", - "validate", - "data", - "reporting", - "before", - "sharing", - "including", - "analytics" - ], - "lifecycle": "Measure", - "use_when": "QA an analysis before sharing, including methodology, accuracy, calculation, visualization, and bias checks. Use when reviewing analysis for stakeholders, spot-checking SQL results, validating aggregation logic, or assessing whether conclusions are supported by the data.", - "do_not_use_when": "Do not use Validate Data when the request is mainly early ideation, qualitative research, or roadmap writing without metrics; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Data validation report with quality issues, methodology checks, and confidence level", - "routing_signals": [ - "validate-data", - "validate", - "data", - "reporting", - "before", - "sharing", - "including", - "methodology", - "analytics", - "accuracy" - ], - "framework_fit": "Appropriate when product metrics, SQL results, dashboards, or warehouse data need verification before decisions or stakeholder communication.", - "failure_modes": [ - "Produces Data validation report with quality issues, methodology checks, and confidence level without tying recommendations to the user's Measure stage, evidence, and decision pressure.", - "Treats Validate Data as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Validate Data when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $validate-data to turn this validate context into a decision-ready Data validation report with quality issues, methodology checks, and confidence level.", - "expected_artifact": "Data validation report with quality issues, methodology checks, and confidence level" - } - ] -} diff --git a/skills/valuation-and-deal-pricing/SKILL.md b/skills/valuation-and-deal-pricing/SKILL.md deleted file mode 100644 index cf0dbefc..00000000 --- a/skills/valuation-and-deal-pricing/SKILL.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -name: valuation-and-deal-pricing -description: >- - Main Productize Finance orchestrator for company valuation, project valuation, - enterprise value, equity value, price per share, VC ownership, dilution, deal pricing, - comparable multiples, precedent transactions, sensitivity tables, and investment - attractiveness decisions. ---- - - - -# Valuation And Deal Pricing - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `valuation-and-deal-pricing` -- **Lifecycle**: Strategize -- **Category**: Finance -- **Primary artifact**: Valuation and deal-pricing memo with method, assumptions, EV, equity value, price per share, sensitivities, recommendation, and warnings - -## Purpose - -Main valuation skill. Use it to answer: - -- What is this company worth? -- What is this project worth? -- What should we pay? -- What ownership should we receive? -- Is this investment attractive? -- What is the enterprise value, equity value, or price per share? - -## Depends On - -- `$finance-modeling-kernel` for formulas, validation, and acceptance-tested calculations. -- `$managerial-finance-dcf` for project DCF, FCF, NPV, IRR, payback, terminal value, and growth value creation. -- `$risk-return-cost-of-capital` for beta, CAPM, WACC, and project-specific discount rates. -- `$capital-structure-financing` for EV-to-equity bridges, leverage, APV, tax shields, debt, preferred, and warrants. -- `$venture-capital-deal-modeling` for VC method, cap tables, dilution, notes, SAFEs, option pools, and preferred stock. -- `$financial-markets-context` for public-market context, comparables, index weights, and market-cap assumptions. - -## Scope - -1. Intrinsic valuation. -2. Relative valuation. -3. Project valuation. -4. Company valuation. -5. VC and startup valuation. -6. Deal pricing. -7. Enterprise value to equity value bridge. -8. Share price and dilution analysis. - -## Core Formulas - -- `PV = C_t / (1 + r)^t` -- `FV_t = C_0 * (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(FCF_t / (1 + r)^t)` -- `EV = sum(FCF_t / (1 + WACC)^t) + TV_N / (1 + WACC)^N` -- `Equity Value = Enterprise Value - Debt - Preferred Stock - Noncontrolling Interest + Cash + Nonoperating Assets` -- `Price per Share = Equity Value / Diluted Shares Outstanding` -- `TV_N = FCF_{N+1} / (WACC - g)` with `WACC > g` -- `TV_N = Exit Multiple * Metric_N` -- `Implied Value = Comparable Multiple * Company Metric` - -## Required Functions - -Use kernel functions for: - -- `value_project_dcf` -- `value_company_dcf` -- `calculate_terminal_value_gordon` -- `calculate_terminal_value_exit_multiple` -- `bridge_enterprise_to_equity_value` -- `calculate_price_per_share` -- `run_comparable_company_valuation` -- `run_precedent_transaction_valuation` -- `calculate_implied_multiple` -- `calculate_implied_value` -- `run_sensitivity_table` -- `run_scenario_analysis` - -## Required Validation - -- Reject Gordon growth if `g >= WACC`. -- Warn if terminal value is more than 70 percent of enterprise value. -- Warn if WACC is used for a project with different risk from the company. -- Warn if book values are used instead of market values. -- Warn if equity value is negative. -- Warn if using EBITDA multiples for companies with very different capex intensity. -- Warn if using revenue multiples without checking gross margin and growth. - -## Required Output - -1. Valuation method used. -2. Key assumptions. -3. Enterprise value. -4. Equity value. -5. Price per share. -6. Sensitivity to WACC and growth. -7. Sensitivity to exit multiple. -8. Decision or recommendation. -9. Warnings. - -Always include the Finance output format: Inputs, Assumptions, Formula used, -Calculation, Result, Interpretation, Warnings. diff --git a/skills/valuation-and-deal-pricing/SKILL.md.tmpl b/skills/valuation-and-deal-pricing/SKILL.md.tmpl deleted file mode 100644 index 247cb89c..00000000 --- a/skills/valuation-and-deal-pricing/SKILL.md.tmpl +++ /dev/null @@ -1,98 +0,0 @@ ---- -name: valuation-and-deal-pricing -description: >- - Main Productize Finance orchestrator for company valuation, project valuation, - enterprise value, equity value, price per share, VC ownership, dilution, deal pricing, - comparable multiples, precedent transactions, sensitivity tables, and investment - attractiveness decisions. ---- - -# Valuation And Deal Pricing - -{{PRODUCTIZE_PREAMBLE}} - -## Purpose - -Main valuation skill. Use it to answer: - -- What is this company worth? -- What is this project worth? -- What should we pay? -- What ownership should we receive? -- Is this investment attractive? -- What is the enterprise value, equity value, or price per share? - -## Depends On - -- `$finance-modeling-kernel` for formulas, validation, and acceptance-tested calculations. -- `$managerial-finance-dcf` for project DCF, FCF, NPV, IRR, payback, terminal value, and growth value creation. -- `$risk-return-cost-of-capital` for beta, CAPM, WACC, and project-specific discount rates. -- `$capital-structure-financing` for EV-to-equity bridges, leverage, APV, tax shields, debt, preferred, and warrants. -- `$venture-capital-deal-modeling` for VC method, cap tables, dilution, notes, SAFEs, option pools, and preferred stock. -- `$financial-markets-context` for public-market context, comparables, index weights, and market-cap assumptions. - -## Scope - -1. Intrinsic valuation. -2. Relative valuation. -3. Project valuation. -4. Company valuation. -5. VC and startup valuation. -6. Deal pricing. -7. Enterprise value to equity value bridge. -8. Share price and dilution analysis. - -## Core Formulas - -- `PV = C_t / (1 + r)^t` -- `FV_t = C_0 * (1 + r)^t` -- `PV stream = sum(C_t / (1 + r)^t)` -- `NPV = -I_0 + sum(FCF_t / (1 + r)^t)` -- `EV = sum(FCF_t / (1 + WACC)^t) + TV_N / (1 + WACC)^N` -- `Equity Value = Enterprise Value - Debt - Preferred Stock - Noncontrolling Interest + Cash + Nonoperating Assets` -- `Price per Share = Equity Value / Diluted Shares Outstanding` -- `TV_N = FCF_{N+1} / (WACC - g)` with `WACC > g` -- `TV_N = Exit Multiple * Metric_N` -- `Implied Value = Comparable Multiple * Company Metric` - -## Required Functions - -Use kernel functions for: - -- `value_project_dcf` -- `value_company_dcf` -- `calculate_terminal_value_gordon` -- `calculate_terminal_value_exit_multiple` -- `bridge_enterprise_to_equity_value` -- `calculate_price_per_share` -- `run_comparable_company_valuation` -- `run_precedent_transaction_valuation` -- `calculate_implied_multiple` -- `calculate_implied_value` -- `run_sensitivity_table` -- `run_scenario_analysis` - -## Required Validation - -- Reject Gordon growth if `g >= WACC`. -- Warn if terminal value is more than 70 percent of enterprise value. -- Warn if WACC is used for a project with different risk from the company. -- Warn if book values are used instead of market values. -- Warn if equity value is negative. -- Warn if using EBITDA multiples for companies with very different capex intensity. -- Warn if using revenue multiples without checking gross margin and growth. - -## Required Output - -1. Valuation method used. -2. Key assumptions. -3. Enterprise value. -4. Equity value. -5. Price per share. -6. Sensitivity to WACC and growth. -7. Sensitivity to exit multiple. -8. Decision or recommendation. -9. Warnings. - -Always include the Finance output format: Inputs, Assumptions, Formula used, -Calculation, Result, Interpretation, Warnings. diff --git a/skills/valuation-and-deal-pricing/agents/openai.yaml b/skills/valuation-and-deal-pricing/agents/openai.yaml deleted file mode 100644 index 3c0ce3b8..00000000 --- a/skills/valuation-and-deal-pricing/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Valuation And Deal Pricing" - short_description: "Main Productize Finance orchestrator for company valuation, project valuation, enterprise value, equity value, price..." - brand_color: "#0369A1" - default_prompt: "Use $valuation-and-deal-pricing with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/valuation-and-deal-pricing/productize.json b/skills/valuation-and-deal-pricing/productize.json deleted file mode 100644 index 9449f4a2..00000000 --- a/skills/valuation-and-deal-pricing/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Valuation And Deal Pricing", - "category": "Finance", - "lifecycle": "Strategize", - "tags": [ - "valuation-and-deal-pricing", - "valuation", - "deal-pricing", - "enterprise-value", - "equity-value", - "price-per-share", - "dcf", - "comparables", - "precedent-transactions", - "sensitivity-analysis", - "investment-decision", - "deal", - "pricing", - "finance" - ], - "use_when": "Use as the main Finance orchestrator when the user asks what a company, project, investment, or deal is worth; what to pay; what ownership to receive; or how EV, equity value, share price, multiples, DCF, and dilution connect.", - "do_not_use_when": "Do not use for narrow formula validation only, pure WACC estimation, pure VC cap table math, or market-context explanation unless the user also needs an integrated valuation or deal recommendation.", - "output_artifact": "Valuation and deal-pricing memo with method, assumptions, EV, equity value, price per share, sensitivities, recommendation, and warnings", - "routing_signals": [ - "what-is-this-company-worth", - "what-should-we-pay", - "deal-pricing", - "enterprise-value", - "equity-value", - "price-per-share", - "comparable-company-valuation", - "precedent-transaction", - "exit-multiple", - "investment-attractive", - "valuation-and-deal-pricing", - "valuation", - "deal", - "pricing" - ], - "framework_fit": "Best when valuation is the user-facing artifact and multiple finance engines may be needed underneath.", - "failure_modes": [ - "Uses a company WACC for a project with materially different risk.", - "Reports ownership percentage without checking dilution, share-count basis, or liquidation preference.", - "Treats a multiple as final truth without triangulating assumptions and comparability.", - "Fails to bridge enterprise value to equity value before calculating price per share." - ], - "examples": [ - { - "prompt": "Use $valuation-and-deal-pricing to value this SaaS company using DCF and public comps, bridge EV to equity value, and recommend what we should pay.", - "expected_artifact": "Valuation and deal-pricing memo with method, assumptions, EV, equity value, price per share, sensitivities, recommendation, and warnings" - } - ] -} diff --git a/skills/value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md b/skills/value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md deleted file mode 100644 index 7d09b1b3..00000000 --- a/skills/value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -name: value-chain-mapping-from-end-user-needs-to-core-value -description: >- - Value chain mapping from end-user needs to core value generators. Use when the user needs a - product workflow for product strategy related to value chain mapping from end-user needs to - core value generators. Trigger terms: strategy, value-chain, business-model, - structured-thinking. ---- - - - -# Value chain mapping from end-user needs to core value generators - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `value-chain-mapping-from-end-user-needs-to-core-value` -- **Lifecycle**: Strategize -- **Category**: Strategy -- **Primary artifact**: Value chain mapping from end-user needs to core value generators strategy memo with choices, tradeoffs, risks, and recommended next move - -Use this skill to run the Productize prompt contract for **Value chain mapping from end-user needs to core value generators**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT}} -- {{INDUSTRY}} - - -GOAL -Produce a high-quality deliverable for: Value chain mapping from end-user needs to core value generators. -Success metric: -- Maps end-user needs to a full value chain and identifies core value generators. -- Highlights vulnerabilities where the chain could be disrupted. -- Grounds analysis in the provided product and industry context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT}}` and `{{INDUSTRY}}`; if information is missing, state assumptions explicitly. -- Map value creation from end-user needs back to foundational inputs. -- Identify core value generators and explain why they are defensible. -- Highlight vulnerabilities and potential disruption points. -- Keep analysis specific to the product/industry context. - -FORMAT -Return exactly this structure: - - -1. End-user needs: - [List the primary needs the product/service fulfills] - -2. Value chain breakdown: - [Provide a hierarchical breakdown of the value chain, from end-user needs to basic inputs] - -3. Core value generators: - [List and explain the identified core value generators] - -4. Potential vulnerabilities: - [Discuss any aspects of the value chain that could be vulnerable to disruption] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Value chain breakdown does not reach foundational inputs. -- Core value generators lack defensible rationale. -- Vulnerabilities are missing or generic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md.tmpl b/skills/value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md.tmpl deleted file mode 100644 index 377dd0e9..00000000 --- a/skills/value-chain-mapping-from-end-user-needs-to-core-value/SKILL.md.tmpl +++ /dev/null @@ -1,69 +0,0 @@ ---- -name: value-chain-mapping-from-end-user-needs-to-core-value -description: >- - Value chain mapping from end-user needs to core value generators. Use when the user needs a - product workflow for product strategy related to value chain mapping from end-user needs to - core value generators. Trigger terms: strategy, value-chain, business-model, - structured-thinking. ---- -# Value chain mapping from end-user needs to core value generators - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Value chain mapping from end-user needs to core value generators**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PRODUCT}} -- {{INDUSTRY}} - - -GOAL -Produce a high-quality deliverable for: Value chain mapping from end-user needs to core value generators. -Success metric: -- Maps end-user needs to a full value chain and identifies core value generators. -- Highlights vulnerabilities where the chain could be disrupted. -- Grounds analysis in the provided product and industry context. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only `{{PRODUCT}}` and `{{INDUSTRY}}`; if information is missing, state assumptions explicitly. -- Map value creation from end-user needs back to foundational inputs. -- Identify core value generators and explain why they are defensible. -- Highlight vulnerabilities and potential disruption points. -- Keep analysis specific to the product/industry context. - -FORMAT -Return exactly this structure: - - -1. End-user needs: - [List the primary needs the product/service fulfills] - -2. Value chain breakdown: - [Provide a hierarchical breakdown of the value chain, from end-user needs to basic inputs] - -3. Core value generators: - [List and explain the identified core value generators] - -4. Potential vulnerabilities: - [Discuss any aspects of the value chain that could be vulnerable to disruption] - - -FAILURE -- Any required section/tag in `FORMAT` is missing, malformed, or incomplete. -- Value chain breakdown does not reach foundational inputs. -- Core value generators lack defensible rationale. -- Vulnerabilities are missing or generic. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/value-chain-mapping-from-end-user-needs-to-core-value/agents/openai.yaml b/skills/value-chain-mapping-from-end-user-needs-to-core-value/agents/openai.yaml deleted file mode 100644 index ae3e963d..00000000 --- a/skills/value-chain-mapping-from-end-user-needs-to-core-value/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Value chain mapping from end-user needs to core value generators" - short_description: "Value chain mapping from end-user needs to core value generators. Use when the user needs a product workflow for..." - brand_color: "#059669" - default_prompt: "Use $value-chain-mapping-from-end-user-needs-to-core-value with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/value-chain-mapping-from-end-user-needs-to-core-value/productize.json b/skills/value-chain-mapping-from-end-user-needs-to-core-value/productize.json deleted file mode 100644 index f6a8e28a..00000000 --- a/skills/value-chain-mapping-from-end-user-needs-to-core-value/productize.json +++ /dev/null @@ -1,38 +0,0 @@ -{ - "title": "Value chain mapping from end-user needs to core value generators", - "category": "Strategy", - "lifecycle": "Strategize", - "tags": [ - "value-chain-mapping-from-end-user-needs-to-core-value", - "value", - "chain", - "mapping", - "end", - "needs", - "core" - ], - "use_when": "Value chain mapping from end-user needs to core value generators. Use when the user needs a product workflow for product strategy related to value chain mapping from end-user needs to core value generators. Trigger terms: strategy, value-chain, business-model, structured-thinking.", - "do_not_use_when": "Do not use Value chain mapping from end-user needs to core value generators when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Value chain mapping from end-user needs to core value generators strategy memo with choices, tradeoffs, risks, and recommended next move", - "routing_signals": [ - "value-chain-mapping-from-end-user-needs-to-core-value", - "value", - "chain", - "mapping", - "end", - "needs", - "core" - ], - "framework_fit": "Value chain mapping from end-user needs to core value generators fits Strategy work in the Strategize lifecycle when the user needs Value chain mapping from end-user needs to core value generators strategy memo with choices, tradeoffs, risks, and recommended next move and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Value chain mapping from end-user needs to core value generators strategy memo with choices, tradeoffs, risks, and recommended next move without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Value chain mapping from end-user needs to core value generators as generic Strategy advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Value chain mapping from end-user needs to core value generators when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $value-chain-mapping-from-end-user-needs-to-core-value to turn this value context into a decision-ready Value chain mapping from end-user needs to core value generators strategy memo with choices, tradeoffs, risks, and recommended next move.", - "expected_artifact": "Value chain mapping from end-user needs to core value generators strategy memo with choices, tradeoffs, risks, and recommended next move" - } - ] -} diff --git a/skills/venture-capital-deal-modeling/SKILL.md b/skills/venture-capital-deal-modeling/SKILL.md deleted file mode 100644 index f9b08015..00000000 --- a/skills/venture-capital-deal-modeling/SKILL.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -name: venture-capital-deal-modeling -description: >- - Productize Finance engine for startup valuation, VC method, pre-money, post-money, - ownership, burn, runway, cap tables, dilution, option pools, convertible notes, - SAFEs, preferred stock payoff waterfalls, and term-sheet analysis. ---- - - - -# Venture Capital Deal Modeling - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `venture-capital-deal-modeling` -- **Lifecycle**: Strategize -- **Category**: Finance -- **Primary artifact**: VC deal model with valuation, ownership, dilution, cap table, instrument treatment, payoff logic, recommendation, and warnings - -## Purpose - -Startup and VC deal skill. Use it for startup valuation, funding rounds, burn/runway, -cap tables, dilution, term sheets, preferred stock, liquidation preferences, -convertible notes, SAFEs, and option pool shuffle. - -## Core Formulas - -- `Monthly Net Burn = Monthly Cash Operating Expenses - Monthly Cash Receipts` -- `Runway in Months = Cash Balance / Monthly Net Burn` -- `Expected Exit Value = Successful Exit Value * p` -- `M = (1 + r_VC)^T / p` -- `PV_company = Successful Exit Value * p / (1 + r_VC)^T` -- `Total Valuation Today = Successful Exit Value * Retention / M` -- `Required Ownership = Required Investment / Total Valuation Today` -- `Post-Money Valuation = Investment / Proposed Ownership Percentage` -- `Pre-Money Valuation = Post-Money Valuation - Investment` -- `Price per Share = Pre-Money Valuation / Pre-Money Fully Diluted Shares` -- `Fully Diluted Shares = Common + Preferred as Converted + Issued Options + Unissued Option Pool + Warrants + Convertibles` -- `Discount Price = (1 - Discount Rate) * Series A Price` -- `Cap Price = Valuation Cap / Cap Share Count` -- `Conversion Price = min(Discount Price, Cap Price)` -- `Liquidation Preference = Original Investment * Liquidation Multiple + Accrued Dividends` -- `Non-participating Payoff = max(Liquidation Preference, As-Converted Ownership * Exit Proceeds)` - -## Required Validation - -- Always specify pre-money versus post-money. -- Always specify basic versus fully diluted shares. -- Always specify whether notes are included in the pre-money valuation. -- Always specify option pool treatment and whether it is before or after financing. -- Always specify whether note interest is simple or compound. -- Always specify whether a SAFE is pre-money or post-money. -- Always specify whether preferred stock is participating or non-participating. -- Always model liquidation preference before common proceeds. -- Warn if ownership percentage is used without checking liquidation preference. -- Warn if the cap table does not sum to 100 percent. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. State the share-count basis and investor/founder impact explicitly. diff --git a/skills/venture-capital-deal-modeling/SKILL.md.tmpl b/skills/venture-capital-deal-modeling/SKILL.md.tmpl deleted file mode 100644 index 413a150c..00000000 --- a/skills/venture-capital-deal-modeling/SKILL.md.tmpl +++ /dev/null @@ -1,54 +0,0 @@ ---- -name: venture-capital-deal-modeling -description: >- - Productize Finance engine for startup valuation, VC method, pre-money, post-money, - ownership, burn, runway, cap tables, dilution, option pools, convertible notes, - SAFEs, preferred stock payoff waterfalls, and term-sheet analysis. ---- - -# Venture Capital Deal Modeling - -{{PRODUCTIZE_PREAMBLE}} - -## Purpose - -Startup and VC deal skill. Use it for startup valuation, funding rounds, burn/runway, -cap tables, dilution, term sheets, preferred stock, liquidation preferences, -convertible notes, SAFEs, and option pool shuffle. - -## Core Formulas - -- `Monthly Net Burn = Monthly Cash Operating Expenses - Monthly Cash Receipts` -- `Runway in Months = Cash Balance / Monthly Net Burn` -- `Expected Exit Value = Successful Exit Value * p` -- `M = (1 + r_VC)^T / p` -- `PV_company = Successful Exit Value * p / (1 + r_VC)^T` -- `Total Valuation Today = Successful Exit Value * Retention / M` -- `Required Ownership = Required Investment / Total Valuation Today` -- `Post-Money Valuation = Investment / Proposed Ownership Percentage` -- `Pre-Money Valuation = Post-Money Valuation - Investment` -- `Price per Share = Pre-Money Valuation / Pre-Money Fully Diluted Shares` -- `Fully Diluted Shares = Common + Preferred as Converted + Issued Options + Unissued Option Pool + Warrants + Convertibles` -- `Discount Price = (1 - Discount Rate) * Series A Price` -- `Cap Price = Valuation Cap / Cap Share Count` -- `Conversion Price = min(Discount Price, Cap Price)` -- `Liquidation Preference = Original Investment * Liquidation Multiple + Accrued Dividends` -- `Non-participating Payoff = max(Liquidation Preference, As-Converted Ownership * Exit Proceeds)` - -## Required Validation - -- Always specify pre-money versus post-money. -- Always specify basic versus fully diluted shares. -- Always specify whether notes are included in the pre-money valuation. -- Always specify option pool treatment and whether it is before or after financing. -- Always specify whether note interest is simple or compound. -- Always specify whether a SAFE is pre-money or post-money. -- Always specify whether preferred stock is participating or non-participating. -- Always model liquidation preference before common proceeds. -- Warn if ownership percentage is used without checking liquidation preference. -- Warn if the cap table does not sum to 100 percent. - -## Required Output - -Return Inputs, Assumptions, Formula used, Calculation, Result, Interpretation, and -Warnings. State the share-count basis and investor/founder impact explicitly. diff --git a/skills/venture-capital-deal-modeling/agents/openai.yaml b/skills/venture-capital-deal-modeling/agents/openai.yaml deleted file mode 100644 index 4ba930d3..00000000 --- a/skills/venture-capital-deal-modeling/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Venture Capital Deal Modeling" - short_description: "Productize Finance engine for startup valuation, VC method, pre-money, post-money, ownership, burn, runway, cap..." - brand_color: "#0369A1" - default_prompt: "Use $venture-capital-deal-modeling with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/venture-capital-deal-modeling/productize.json b/skills/venture-capital-deal-modeling/productize.json deleted file mode 100644 index b84fdc59..00000000 --- a/skills/venture-capital-deal-modeling/productize.json +++ /dev/null @@ -1,52 +0,0 @@ -{ - "title": "Venture Capital Deal Modeling", - "category": "Finance", - "lifecycle": "Strategize", - "tags": [ - "venture-capital-deal-modeling", - "vc-method", - "startup-valuation", - "pre-money", - "post-money", - "cap-table", - "dilution", - "convertible-notes", - "safe", - "option-pool", - "preferred-stock", - "liquidation-preference", - "runway", - "venture" - ], - "use_when": "Use when valuing a startup, calculating pre-money/post-money, ownership, shares, dilution, burn/runway, cap tables, convertible notes, SAFEs, option pools, preferred stock payoffs, or term-sheet economics.", - "do_not_use_when": "Do not use for mature-company DCF, public comparables, bond math, or generic capital structure unless startup financing instruments drive the decision.", - "output_artifact": "VC deal model with valuation, ownership, dilution, cap table, instrument treatment, payoff logic, recommendation, and warnings", - "routing_signals": [ - "vc-deal", - "startup-valuation", - "pre-money", - "post-money", - "cap-table", - "dilution", - "convertible-note", - "safe", - "option-pool", - "preferred-stock", - "liquidation-preference", - "term-sheet", - "runway", - "burn-rate" - ], - "framework_fit": "Best when startup deal economics, share counts, dilution, and investor/founder terms are central.", - "failure_modes": [ - "Produces VC deal model with valuation, ownership, dilution, cap table, instrument treatment, payoff logic, recommendation, and warnings without tying recommendations to the user's Strategize stage, evidence, and decision pressure.", - "Treats Venture Capital Deal Modeling as generic Finance advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Venture Capital Deal Modeling when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $venture-capital-deal-modeling to model a Series A with a pre-money valuation, option pool increase, convertible note, and 1x non-participating preferred.", - "expected_artifact": "VC deal model with valuation, ownership, dilution, cap table, instrument treatment, payoff logic, recommendation, and warnings" - } - ] -} diff --git a/skills/verification/SKILL.md b/skills/verification/SKILL.md deleted file mode 100644 index b487b31d..00000000 --- a/skills/verification/SKILL.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -name: verification -description: >- - Verify before claiming completion. No claims without fresh verification evidence. Use before - marking work done. ---- - - - -# Verification Before Completion - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `verification` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Verification evidence checklist and completion decision - -Use when about to claim work is complete, fixed, or passing. - -## Implementation Notes Check - -If the task used `$implementation-notes`, fresh verification includes checking the -notes file against the actual final work: - -- decisions and deviations still match the diff -- open questions are current -- verification results are recorded -- untested behavior is named - -Do not claim completion if the implementation-notes file is stale relative to the -final code, docs, tests, or release state. - -## The Iron Law - -``` -NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE -``` - -If you haven't run the verification command in this message, you cannot claim it passes. - -## The Gate Function - -Before claiming any status or completion: - -1. **IDENTIFY** - What command proves this claim? -2. **RUN** - Execute the FULL command (fresh, complete) -3. **READ** - Full output, check exit code, count failures -4. **VERIFY** - Does output confirm the claim? - - If NO: State actual status with evidence - - If YES: State claim WITH evidence -5. **ONLY THEN** - Make the claim - -Skip any step = lying, not verifying. - -## What Requires Verification - -| Claim | Requires | Not Sufficient | -|-------|----------|----------------| -| Tests pass | Test command output: 0 failures | Previous run, "should pass" | -| Linter clean | Linter output: 0 errors | Partial check | -| Build succeeds | Build command: exit 0 | Linter passing | -| Bug fixed | Test original symptom: passes | Code changed | -| Phase complete | All objectives verified | Tests passing | -| Task done | Checklist items verified | "I did everything" | - -## Red Flags - STOP - -- Using "should", "probably", "seems to" -- Expressing satisfaction before verification ("Great!", "Done!") -- About to commit/push without verification -- Relying on partial verification -- ANY wording implying success without having run verification - -## Patterns - -**Tests:** -``` -OK: [Run test] [See: 34/34 pass] "All tests pass" -BAD: "Should pass now" -``` - -**Build:** -``` -OK: [Run build] [See: exit 0] "Build passes" -BAD: "Linter passed" (linter != compiler) -``` - -**Task completion:** -``` -OK: Re-read requirements -> checklist -> verify each -> report -BAD: "Tests pass, task complete" -``` - -## Common Rationalizations - -| Excuse | Reality | -|--------|---------| -| "Should work now" | Run the verification | -| "I'm confident" | Confidence != evidence | -| "Just this once" | No exceptions | -| "Partial check is enough" | Partial proves nothing | - -## The Bottom Line - -Run the command. Read the output. Then claim the result. - -No shortcuts. Non-negotiable. - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/verification/SKILL.md.tmpl b/skills/verification/SKILL.md.tmpl deleted file mode 100644 index 4cb25e81..00000000 --- a/skills/verification/SKILL.md.tmpl +++ /dev/null @@ -1,108 +0,0 @@ ---- -name: verification -description: >- - Verify before claiming completion. No claims without fresh verification evidence. Use before - marking work done. ---- -# Verification Before Completion - -{{PRODUCTIZE_PREAMBLE}} - -Use when about to claim work is complete, fixed, or passing. - -## Implementation Notes Check - -If the task used `$implementation-notes`, fresh verification includes checking the -notes file against the actual final work: - -- decisions and deviations still match the diff -- open questions are current -- verification results are recorded -- untested behavior is named - -Do not claim completion if the implementation-notes file is stale relative to the -final code, docs, tests, or release state. - -## The Iron Law - -``` -NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE -``` - -If you haven't run the verification command in this message, you cannot claim it passes. - -## The Gate Function - -Before claiming any status or completion: - -1. **IDENTIFY** - What command proves this claim? -2. **RUN** - Execute the FULL command (fresh, complete) -3. **READ** - Full output, check exit code, count failures -4. **VERIFY** - Does output confirm the claim? - - If NO: State actual status with evidence - - If YES: State claim WITH evidence -5. **ONLY THEN** - Make the claim - -Skip any step = lying, not verifying. - -## What Requires Verification - -| Claim | Requires | Not Sufficient | -|-------|----------|----------------| -| Tests pass | Test command output: 0 failures | Previous run, "should pass" | -| Linter clean | Linter output: 0 errors | Partial check | -| Build succeeds | Build command: exit 0 | Linter passing | -| Bug fixed | Test original symptom: passes | Code changed | -| Phase complete | All objectives verified | Tests passing | -| Task done | Checklist items verified | "I did everything" | - -## Red Flags - STOP - -- Using "should", "probably", "seems to" -- Expressing satisfaction before verification ("Great!", "Done!") -- About to commit/push without verification -- Relying on partial verification -- ANY wording implying success without having run verification - -## Patterns - -**Tests:** -``` -OK: [Run test] [See: 34/34 pass] "All tests pass" -BAD: "Should pass now" -``` - -**Build:** -``` -OK: [Run build] [See: exit 0] "Build passes" -BAD: "Linter passed" (linter != compiler) -``` - -**Task completion:** -``` -OK: Re-read requirements -> checklist -> verify each -> report -BAD: "Tests pass, task complete" -``` - -## Common Rationalizations - -| Excuse | Reality | -|--------|---------| -| "Should work now" | Run the verification | -| "I'm confident" | Confidence != evidence | -| "Just this once" | No exceptions | -| "Partial check is enough" | Partial proves nothing | - -## The Bottom Line - -Run the command. Read the output. Then claim the result. - -No shortcuts. Non-negotiable. - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/verification/agents/openai.yaml b/skills/verification/agents/openai.yaml deleted file mode 100644 index 10af9b23..00000000 --- a/skills/verification/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Verification" - short_description: "Verify before claiming completion. No claims without fresh verification evidence. Use before marking work done." - brand_color: "#334155" - default_prompt: "Use $verification with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/verification/productize.json b/skills/verification/productize.json deleted file mode 100644 index 67103b52..00000000 --- a/skills/verification/productize.json +++ /dev/null @@ -1,48 +0,0 @@ -{ - "title": "Verification", - "category": "AI Execution", - "tags": [ - "verification", - "completion-checks", - "testing", - "build-validation", - "quality-gate", - "evidence", - "technical", - "verify", - "before", - "claiming", - "completion", - "claims", - "without", - "fresh" - ], - "lifecycle": "Build With AI", - "use_when": "Verify before claiming completion. No claims without fresh verification evidence. Use before marking work done.", - "do_not_use_when": "Do not use Verification when the request is mainly market strategy, research synthesis, finance modeling, or executive communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Verification evidence checklist and completion decision", - "routing_signals": [ - "verification", - "technical", - "verify", - "before", - "claiming", - "completion", - "claims", - "without", - "fresh", - "execution" - ], - "framework_fit": "Appropriate when an AI builder, PM, or engineer needs fresh evidence before claiming implementation, spec, or artifact completion.", - "failure_modes": [ - "Produces Verification evidence checklist and completion decision without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats Verification as generic AI Execution advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Verification when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $verification to turn this technical context into a decision-ready Verification evidence checklist and completion decision.", - "expected_artifact": "Verification evidence checklist and completion decision" - } - ] -} diff --git a/skills/visual-decision-making-review/SKILL.md b/skills/visual-decision-making-review/SKILL.md deleted file mode 100644 index 28088ed9..00000000 --- a/skills/visual-decision-making-review/SKILL.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -name: visual-decision-making-review -description: >- - Review how visuals, charts, diagrams, canvases, dashboards, or slides may shape a product - decision. Use when the user needs to identify visual bias, overconfidence, misleading - emphasis, graph validity issues, or decision stickiness caused by the visual artifact. ---- - - - -# Visual Decision Making Review - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `visual-decision-making-review` -- **Lifecycle**: Think -- **Category**: Decision Making -- **Primary artifact**: Visual decision-making review with salience map, decision value, visual risks, corrections, and decision recommendation - -Use this skill when the visual itself is part of the decision-making risk. This is not a -chart-building skill. It reviews whether a visual artifact helps decision quality or creates -false confidence, hidden emphasis, misleading comparisons, or sticky first impressions. - -Route to `data-visualization` when the user needs to choose chart types or create charts. -Use this skill when the question is whether the visual will distort or improve a decision. - -## Decision-Making Principles - -- Visuals expand working memory and can turn implicit information into a shared decision format. -- Repeated visual frameworks can improve pattern recognition and knowledge transfer. -- Visuals also create decision risks: detail can imply relevance, polish can imply correctness, - formatting can hide weak evidence, and emphasized elements can blind the group to alternatives. -- Original visuals can become sticky anchors, especially in meetings and executive reviews. -- Cultural, language, and perception differences can change how a visual is interpreted. - -## Workflow - -1. Identify the decision the visual is meant to support. -2. Identify the visual type and what it makes salient. -3. Check whether the visual offloads complexity or oversimplifies the problem. -4. Audit validity, scale, labeling, uncertainty, source, and construction errors. -5. Identify emphasis, omissions, anchors, and overconfidence risks. -6. Recommend visual changes and decision-process safeguards. - -## Output Contract - -Return: - -```markdown -# Visual Decision Making Review - -## 1. Decision Context -Decision: -Audience: -Visual artifact: -Decision moment: - -## 2. What The Visual Makes Salient -Main message: -Highlighted elements: -Hidden or de-emphasized elements: -Likely first impression: - -## 3. Decision Value -Working-memory support: -Pattern recognition: -Shared format: -Knowledge transfer: - -## 4. Visual Decision Risks -Relevance overconfidence: -Formatting illusion: -Validity / construction issues: -Robustness / stickiness: -Blind-sighting or emphasis risk: -Cultural or interpretation risk: - -## 5. Corrections -Visual changes: -Evidence labels: -Alternative views: -Uncertainty or caveats: -Meeting safeguards: - -## 6. Decision Recommendation -Use as-is / revise / replace / supplement: -Why: -Next action: -``` - -## Failure Modes - -- Gives generic chart advice without analyzing decision impact. -- Treats polished visuals as reliable without checking evidence and construction. -- Fails to identify what the visual emphasizes and what it hides. -- Omits decision-process safeguards such as alternative views, caveats, or private review. diff --git a/skills/visual-decision-making-review/SKILL.md.tmpl b/skills/visual-decision-making-review/SKILL.md.tmpl deleted file mode 100644 index c9e9b053..00000000 --- a/skills/visual-decision-making-review/SKILL.md.tmpl +++ /dev/null @@ -1,88 +0,0 @@ ---- -name: visual-decision-making-review -description: >- - Review how visuals, charts, diagrams, canvases, dashboards, or slides may shape a product - decision. Use when the user needs to identify visual bias, overconfidence, misleading - emphasis, graph validity issues, or decision stickiness caused by the visual artifact. ---- -# Visual Decision Making Review - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill when the visual itself is part of the decision-making risk. This is not a -chart-building skill. It reviews whether a visual artifact helps decision quality or creates -false confidence, hidden emphasis, misleading comparisons, or sticky first impressions. - -Route to `data-visualization` when the user needs to choose chart types or create charts. -Use this skill when the question is whether the visual will distort or improve a decision. - -## Decision-Making Principles - -- Visuals expand working memory and can turn implicit information into a shared decision format. -- Repeated visual frameworks can improve pattern recognition and knowledge transfer. -- Visuals also create decision risks: detail can imply relevance, polish can imply correctness, - formatting can hide weak evidence, and emphasized elements can blind the group to alternatives. -- Original visuals can become sticky anchors, especially in meetings and executive reviews. -- Cultural, language, and perception differences can change how a visual is interpreted. - -## Workflow - -1. Identify the decision the visual is meant to support. -2. Identify the visual type and what it makes salient. -3. Check whether the visual offloads complexity or oversimplifies the problem. -4. Audit validity, scale, labeling, uncertainty, source, and construction errors. -5. Identify emphasis, omissions, anchors, and overconfidence risks. -6. Recommend visual changes and decision-process safeguards. - -## Output Contract - -Return: - -```markdown -# Visual Decision Making Review - -## 1. Decision Context -Decision: -Audience: -Visual artifact: -Decision moment: - -## 2. What The Visual Makes Salient -Main message: -Highlighted elements: -Hidden or de-emphasized elements: -Likely first impression: - -## 3. Decision Value -Working-memory support: -Pattern recognition: -Shared format: -Knowledge transfer: - -## 4. Visual Decision Risks -Relevance overconfidence: -Formatting illusion: -Validity / construction issues: -Robustness / stickiness: -Blind-sighting or emphasis risk: -Cultural or interpretation risk: - -## 5. Corrections -Visual changes: -Evidence labels: -Alternative views: -Uncertainty or caveats: -Meeting safeguards: - -## 6. Decision Recommendation -Use as-is / revise / replace / supplement: -Why: -Next action: -``` - -## Failure Modes - -- Gives generic chart advice without analyzing decision impact. -- Treats polished visuals as reliable without checking evidence and construction. -- Fails to identify what the visual emphasizes and what it hides. -- Omits decision-process safeguards such as alternative views, caveats, or private review. diff --git a/skills/visual-decision-making-review/agents/openai.yaml b/skills/visual-decision-making-review/agents/openai.yaml deleted file mode 100644 index 416711b5..00000000 --- a/skills/visual-decision-making-review/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Visual Decision Making Review" - short_description: "Review how visuals, charts, diagrams, canvases, dashboards, or slides may shape a product decision. Use when the..." - brand_color: "#7C2D12" - default_prompt: "Use $visual-decision-making-review with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/visual-decision-making-review/productize.json b/skills/visual-decision-making-review/productize.json deleted file mode 100644 index 728fb136..00000000 --- a/skills/visual-decision-making-review/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Visual Decision Making Review", - "category": "Decision Making", - "lifecycle": "Think", - "tags": [ - "visual-decision-making", - "visual-bias", - "chart-review", - "decision-visualization", - "misleading-visuals", - "overconfidence", - "graph-validity", - "visual-anchoring", - "dashboard-review", - "visual-decision-making-review", - "visual", - "decision", - "making", - "review" - ], - "use_when": "Use when a chart, dashboard, slide, diagram, canvas, or visual framework may affect a product or executive decision and needs review for visual bias, overconfidence, emphasis, validity, or decision stickiness.", - "do_not_use_when": "Do not use when the user simply needs to build a chart, select chart types, or write Python visualization code; route that to data-visualization or create-viz.", - "output_artifact": "Visual decision-making review with salience map, decision value, visual risks, corrections, and decision recommendation", - "routing_signals": [ - "visual-decision-making", - "visual-bias", - "decision-visualization", - "misleading-chart", - "chart-bias", - "graph-validity", - "visual-overconfidence", - "dashboard-decision", - "visual-anchor", - "will-this-chart-bias", - "visual-decision-making-review", - "visual", - "decision", - "making" - ], - "framework_fit": "Best when a visual artifact is being used to make or influence a decision and the user needs to know whether it improves or distorts judgment.", - "failure_modes": [ - "Gives generic visualization advice instead of reviewing decision impact.", - "Misses misleading emphasis, hidden alternatives, or visual anchoring.", - "Fails to distinguish visual polish from evidence validity.", - "Omits corrective alternatives or decision-process safeguards." - ], - "examples": [ - { - "prompt": "Use $visual-decision-making-review to review this dashboard before the exec team decides whether to cut onboarding scope.", - "expected_artifact": "Visual decision-making review with salience map, decision value, visual risks, corrections, and decision recommendation" - } - ] -} diff --git a/skills/workflow-memory/SKILL.md b/skills/workflow-memory/SKILL.md new file mode 100644 index 00000000..698e9635 --- /dev/null +++ b/skills/workflow-memory/SKILL.md @@ -0,0 +1,85 @@ +--- +name: workflow-memory +description: Maintains workflow-scoped task memory for Productize runs using .productize/tasks//memory/ files. Use when a task prompt provides workflow memory paths and requires the agent to read, update, compact, and promote durable context across PRD task executions. Do not use for PR review remediation, global user preferences, or programmatic event-log summarization. +--- + +# Workflow Memory + +Maintain the workflow memory files provided by the caller. + +## Required Inputs + +- Workflow memory directory path. +- Shared workflow memory file path. +- Current task memory file path. +- Optional caller signal indicating whether either file must be compacted before proceeding. + +## Workflow + +1. Load the memory state before editing code. + - Read the shared workflow memory file and the current task memory file before making any code change. + - Treat these files as mandatory context for the run, not optional notes. + - If the caller marks either file for compaction, read `references/memory-guidelines.md` and compact that file before proceeding with implementation. + +2. Keep memory current while the task runs. + - Update the current task memory whenever the objective changes, a non-obvious decision is made, an important learning appears, or an error changes the plan. + - Promote only durable cross-task context into the shared workflow memory. + - Keep task-local execution details in the current task memory file. + +3. Close out the run cleanly. + - Update memory before any completion claim, handoff, or commit. + - Record only facts that help the next run start faster and with fewer mistakes. + - Re-read `references/memory-guidelines.md` before compacting if the file has grown noisy or repetitive. + +## Critical Rules + +- Do not invent history, decisions, or status that did not happen. +- Do not copy large code blocks, stack traces, or task specs into memory files. +- Do not duplicate facts that are obvious from the repository, git diff, task file, or PRD documents. +- Do not read unrelated task memory files unless the shared workflow memory or the caller explicitly points to them. +- Keep shared memory durable and cross-task. Keep task memory local and operational. + +## Promotion Decision Test + +Before promoting an item from task memory to shared workflow memory, ask: + +1. Will another task need this information to avoid a mistake or rediscovery? +2. Is this fact durable across multiple runs, not just the current execution? +3. Is this information NOT already obvious from the PRD, techspec, task files, or the repository itself? + +All three must be "yes" to promote. If any is "no," the item stays in task memory. + +**Examples that belong in shared workflow memory:** +- A discovered constraint that affects multiple tasks (e.g., "the API rate limits to 100 req/s, batch operations must respect this") +- A cross-cutting architectural decision made during implementation (e.g., "chose channel-based coordination over mutex for the pipeline") +- An open risk that future tasks must account for (e.g., "migration depends on schema v3 which is not yet deployed to staging") + +**Examples that stay in task memory:** +- Files touched during this task's implementation +- Debugging steps taken to resolve a task-specific error +- The current task's objective and acceptance criteria snapshot +- A workaround applied only to the current task's scope + +## Compaction Rules + +When the caller flags a memory file for compaction, apply these rules inline. Read `references/memory-guidelines.md` for full detail, but these rules are sufficient for most compaction passes: + +1. If both files need compaction, compact the shared workflow memory first, then compact the task memory. The shared file sets the cross-task context that the task file should not duplicate. +2. **Preserve:** current state, durable decisions, reusable learnings, open risks, and handoff notes. +3. **Remove:** repetition, stale notes, long command transcripts, and facts already derivable from the repository, PRD, or task files. +4. **Rewrite** retained items as short factual bullets. Do not preserve narrative logs or chronological play-by-play. +5. Keep the default section headings from the template intact. Remove empty sections only if they are truly unused. + +## When To Read the Reference + +Read `references/memory-guidelines.md` when any of these apply: + +- the caller requests compaction and the inline rules above do not cover the situation +- it is unclear what belongs in shared memory versus task memory +- the current memory file has drifted into noisy notes or redundant detail + +## Error Handling + +- If any caller-provided memory path is missing, stop and report the mismatch instead of guessing another path. +- If memory content conflicts with the repository or task specification, trust the repository and task documents, then correct the memory file. +- If compaction would remove active risks, decisions, or handoff context, keep those items and remove lower-value repetition first. diff --git a/skills/workflow-memory/references/memory-guidelines.md b/skills/workflow-memory/references/memory-guidelines.md new file mode 100644 index 00000000..0654ff34 --- /dev/null +++ b/skills/workflow-memory/references/memory-guidelines.md @@ -0,0 +1,75 @@ +# Workflow Memory Guidelines + +Use these rules to keep Productize workflow memory useful across repeated PRD task runs. + +## File Roles + +### Shared workflow memory: `MEMORY.md` + +Use the shared workflow memory for context that should survive across multiple tasks and multiple runs. + +Keep: +- current workflow state that affects more than one task +- durable technical or product decisions +- reusable learnings that will matter again +- open risks or handoff notes that change future execution + +Avoid: +- step-by-step scratch notes +- large code excerpts +- facts that are already explicit in `_prd.md`, `_techspec.md`, `_tasks.md`, or the repo itself + +### Current task memory: `memory/` + +Use the task memory for context that is specific to the current task. + +Keep: +- the current objective snapshot +- important task-local decisions +- local learnings and corrections +- touched files or surfaces worth remembering next run +- ready-for-next-run notes + +Avoid: +- cross-task summaries that belong in `MEMORY.md` +- repeated restatements of the task spec +- low-signal command transcripts + +## Promotion Rules + +Promote an item from task memory into shared workflow memory only when it is: +- durable across runs +- useful to another task +- likely to prevent repeated mistakes or rediscovery + +Leave information in task memory when it is: +- operational only for the current task +- temporary +- too detailed for workflow-wide reuse + +## Compaction Rules + +When compaction is required: +- preserve current state, durable decisions, reusable learnings, open risks, and handoffs +- remove repetition, stale notes, long transcripts, and derivable facts +- rewrite for clarity, not for completeness +- prefer short factual bullets over narrative logs + +## Default Section Boundaries + +### `MEMORY.md` + +- `## Current State` +- `## Shared Decisions` +- `## Shared Learnings` +- `## Open Risks` +- `## Handoffs` + +### `memory/` + +- `## Objective Snapshot` +- `## Important Decisions` +- `## Learnings` +- `## Files / Surfaces` +- `## Errors / Corrections` +- `## Ready for Next Run` diff --git a/skills/workshop-activity-design-from-problem-and-participant/SKILL.md b/skills/workshop-activity-design-from-problem-and-participant/SKILL.md deleted file mode 100644 index f4990832..00000000 --- a/skills/workshop-activity-design-from-problem-and-participant/SKILL.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -name: workshop-activity-design-from-problem-and-participant -description: >- - Workshop activity design from problem and participant parameters. Use when the user needs a - product workflow for design & prototyping related to workshop activity design from problem - and participant parameters. Trigger terms: workshops, facilitation, brainstorming, product, - ux. ---- - - - -# Workshop activity design from problem and participant parameters - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `workshop-activity-design-from-problem-and-participant` -- **Lifecycle**: Design -- **Category**: Operations -- **Primary artifact**: Workshop activity design from problem and participant parameters UX/design review with findings, constraints, fixes, and acceptance checks - -Use this skill to run the Productize prompt contract for **Workshop activity design from problem and participant parameters**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM}} -- {{PARTICIPANTS}} -- {{TIME_AVAILABLE}} -- {{PLATFORM}} - - -GOAL -Produce a high-quality deliverable for: "Workshop activity design from problem and participant parameters". -Success metric: -- Produces 3-5 distinct workshop activity variants tailored to problem, participants, time, and platform. -- Each variant is facilitator-ready, includes exact timing, and is feasible within `{{TIME_AVAILABLE}}`. -- Variants include practical tradeoffs, inclusion mechanics, and clear runbooks. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if any input is incomplete, state explicit assumptions per variant. -- Generate 3-5 distinct variants. -- Do not use XML or JSON anywhere in the response. -- For each variant, total duration must be `<= {{TIME_AVAILABLE}}`, and timeline minute ranges must sum exactly to the stated total. -- Adapt mechanics by participant size: - - `<=8`: whole-group flow with silent ideation first. - - `9-20`: pods of 3-5 with rotating roles/report-outs. - - `>20`: swarm + pods (4-6) + gallery walk + synthesis. -- Adapt logistics by platform: - - `remote/hybrid`: breakout choreography and linked board flow. - - `in-person`: room setup, physical materials, visible timing controls. -- Include inclusion and bias-mitigation mechanisms (silent write, timeboxing, anonymous voting, speaker rotation, accessibility notes). -- Include practical Miro runbook guidance for intermediate users; if in-person-only with no Miro, write `Not applicable`. -- Across the full set of variants, include at least: - - one rapid ideation pattern, - - one prioritization pattern, - - one synthesis pattern. -- Keep language facilitator-ready and operational. - -FORMAT -Return exactly this structure: - -Here are multiple workshop activity variants designed to address the given problem(s): - -### Variant X: *[Activity Name]* -**Assumptions** -- [Assumptions] - -**Overview (2-3 sentences)** -- [Overview] - -**Rationale** -- [Why it fits problem, participants, time, platform] - -**Duration** -- **Total minutes:** [N] - -**Timeline (minute-by-minute; sums to total)** -- 00:00-00:XX โ€” [Step] -- 00:XX-00:YY โ€” [Step] - -**Facilitator Process** -1. [Concrete facilitator step with timing] -2. [Concrete facilitator step with timing] -- **Scaling notes:** [<=8 | 9-20 | >20 adaptations] -- **If time slips +/-10%:** [What to shorten/extend] - -**Participant Process** -1. [What participants do] -2. [What participants produce/decide] - -**Miro Setup & Runbook (intermediate)** -- [Board prep, frames, breakouts, timer, voting, mapping, export] -- [If not applicable: "Not applicable"] - -**Inputs (bring to the workshop)** -- [Inputs] - -**Outputs (created by the activity)** -- [Outputs] - -**Pros** -- [Pros] - -**Cons (with mitigations)** -- [Cons + mitigation] - -[Repeat full variant structure for 3-5 variants] - -FAILURE -- Opening line is missing or different from required text. -- Fewer than 3 or more than 5 variants are provided. -- Any variant exceeds `{{TIME_AVAILABLE}}` or timeline math does not sum to stated total. -- Output contains XML or JSON. -- Variant sections are missing required headings/items from `FORMAT`. -- Participant-size and platform adaptations are not reflected. -- Miro runbook is missing (or not marked `Not applicable` when appropriate). -- Required pattern coverage across the set (rapid ideation, prioritization, synthesis) is incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/workshop-activity-design-from-problem-and-participant/SKILL.md.tmpl b/skills/workshop-activity-design-from-problem-and-participant/SKILL.md.tmpl deleted file mode 100644 index f6a53453..00000000 --- a/skills/workshop-activity-design-from-problem-and-participant/SKILL.md.tmpl +++ /dev/null @@ -1,121 +0,0 @@ ---- -name: workshop-activity-design-from-problem-and-participant -description: >- - Workshop activity design from problem and participant parameters. Use when the user needs a - product workflow for design & prototyping related to workshop activity design from problem - and participant parameters. Trigger terms: workshops, facilitation, brainstorming, product, - ux. ---- -# Workshop activity design from problem and participant parameters - -{{PRODUCTIZE_PREAMBLE}} - -Use this skill to run the Productize prompt contract for **Workshop activity design from problem and participant parameters**. - -## Instructions - -1. Treat every `{{PLACEHOLDER}}` in the contract as an input to collect, infer, or mark as missing. -2. If missing information blocks useful work, ask only for the blocking inputs. If work can proceed, state assumptions explicitly. -3. Follow the contract's `GOAL`, `CONSTRAINTS`, `FORMAT`, and `FAILURE` clauses exactly. -4. Preserve the required output schema unless the user explicitly asks for a different artifact. -5. Keep claims grounded in the provided inputs and disclose gaps. - -## Prompt Contract - -INPUTS - -- {{PROBLEM}} -- {{PARTICIPANTS}} -- {{TIME_AVAILABLE}} -- {{PLATFORM}} - - -GOAL -Produce a high-quality deliverable for: "Workshop activity design from problem and participant parameters". -Success metric: -- Produces 3-5 distinct workshop activity variants tailored to problem, participants, time, and platform. -- Each variant is facilitator-ready, includes exact timing, and is feasible within `{{TIME_AVAILABLE}}`. -- Variants include practical tradeoffs, inclusion mechanics, and clear runbooks. -- Output follows the required structure exactly. - -CONSTRAINTS -- Use only provided inputs; if any input is incomplete, state explicit assumptions per variant. -- Generate 3-5 distinct variants. -- Do not use XML or JSON anywhere in the response. -- For each variant, total duration must be `<= {{TIME_AVAILABLE}}`, and timeline minute ranges must sum exactly to the stated total. -- Adapt mechanics by participant size: - - `<=8`: whole-group flow with silent ideation first. - - `9-20`: pods of 3-5 with rotating roles/report-outs. - - `>20`: swarm + pods (4-6) + gallery walk + synthesis. -- Adapt logistics by platform: - - `remote/hybrid`: breakout choreography and linked board flow. - - `in-person`: room setup, physical materials, visible timing controls. -- Include inclusion and bias-mitigation mechanisms (silent write, timeboxing, anonymous voting, speaker rotation, accessibility notes). -- Include practical Miro runbook guidance for intermediate users; if in-person-only with no Miro, write `Not applicable`. -- Across the full set of variants, include at least: - - one rapid ideation pattern, - - one prioritization pattern, - - one synthesis pattern. -- Keep language facilitator-ready and operational. - -FORMAT -Return exactly this structure: - -Here are multiple workshop activity variants designed to address the given problem(s): - -### Variant X: *[Activity Name]* -**Assumptions** -- [Assumptions] - -**Overview (2-3 sentences)** -- [Overview] - -**Rationale** -- [Why it fits problem, participants, time, platform] - -**Duration** -- **Total minutes:** [N] - -**Timeline (minute-by-minute; sums to total)** -- 00:00-00:XX โ€” [Step] -- 00:XX-00:YY โ€” [Step] - -**Facilitator Process** -1. [Concrete facilitator step with timing] -2. [Concrete facilitator step with timing] -- **Scaling notes:** [<=8 | 9-20 | >20 adaptations] -- **If time slips +/-10%:** [What to shorten/extend] - -**Participant Process** -1. [What participants do] -2. [What participants produce/decide] - -**Miro Setup & Runbook (intermediate)** -- [Board prep, frames, breakouts, timer, voting, mapping, export] -- [If not applicable: "Not applicable"] - -**Inputs (bring to the workshop)** -- [Inputs] - -**Outputs (created by the activity)** -- [Outputs] - -**Pros** -- [Pros] - -**Cons (with mitigations)** -- [Cons + mitigation] - -[Repeat full variant structure for 3-5 variants] - -FAILURE -- Opening line is missing or different from required text. -- Fewer than 3 or more than 5 variants are provided. -- Any variant exceeds `{{TIME_AVAILABLE}}` or timeline math does not sum to stated total. -- Output contains XML or JSON. -- Variant sections are missing required headings/items from `FORMAT`. -- Participant-size and platform adaptations are not reflected. -- Miro runbook is missing (or not marked `Not applicable` when appropriate). -- Required pattern coverage across the set (rapid ideation, prioritization, synthesis) is incomplete. -- Claims are generic or not grounded in provided inputs. -- Assumptions are used but not explicitly stated. diff --git a/skills/workshop-activity-design-from-problem-and-participant/agents/openai.yaml b/skills/workshop-activity-design-from-problem-and-participant/agents/openai.yaml deleted file mode 100644 index 929dad77..00000000 --- a/skills/workshop-activity-design-from-problem-and-participant/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Workshop activity design from problem and participant parameters" - short_description: "Workshop activity design from problem and participant parameters. Use when the user needs a product workflow for..." - brand_color: "#7C3AED" - default_prompt: "Use $workshop-activity-design-from-problem-and-participant with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/workshop-activity-design-from-problem-and-participant/productize.json b/skills/workshop-activity-design-from-problem-and-participant/productize.json deleted file mode 100644 index d807ba4d..00000000 --- a/skills/workshop-activity-design-from-problem-and-participant/productize.json +++ /dev/null @@ -1,36 +0,0 @@ -{ - "title": "Workshop activity design from problem and participant parameters", - "category": "Operations", - "lifecycle": "Design", - "tags": [ - "workshop-activity-design-from-problem-and-participant", - "workshop", - "activity", - "design", - "problem", - "participant" - ], - "use_when": "Workshop activity design from problem and participant parameters. Use when the user needs a product workflow for design & prototyping related to workshop activity design from problem and participant parameters. Trigger terms: workshops, facilitation, brainstorming, product, ux.", - "do_not_use_when": "Do not use Workshop activity design from problem and participant parameters when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Workshop activity design from problem and participant parameters UX/design review with findings, constraints, fixes, and acceptance checks", - "routing_signals": [ - "workshop-activity-design-from-problem-and-participant", - "workshop", - "activity", - "design", - "problem", - "participant" - ], - "framework_fit": "Workshop activity design from problem and participant parameters fits Operations work in the Design lifecycle when the user needs Workshop activity design from problem and participant parameters UX/design review with findings, constraints, fixes, and acceptance checks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Workshop activity design from problem and participant parameters UX/design review with findings, constraints, fixes, and acceptance checks without tying recommendations to the user's Design stage, evidence, and decision pressure.", - "Treats Workshop activity design from problem and participant parameters as generic Operations advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Workshop activity design from problem and participant parameters when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $workshop-activity-design-from-problem-and-participant to turn this workshop context into a decision-ready Workshop activity design from problem and participant parameters UX/design review with findings, constraints, fixes, and acceptance checks.", - "expected_artifact": "Workshop activity design from problem and participant parameters UX/design review with findings, constraints, fixes, and acceptance checks" - } - ] -} diff --git a/skills/write-query/SKILL.md b/skills/write-query/SKILL.md deleted file mode 100644 index 80558dca..00000000 --- a/skills/write-query/SKILL.md +++ /dev/null @@ -1,209 +0,0 @@ ---- -name: write-query -description: >- - Write optimized SQL for a specific dialect with best practices. Use when translating a natural - language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing - a large partitioned-table query, or getting Snowflake, BigQuery, Postgres, or other dialect syntax. ---- - - - -# Write Query - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `write-query` -- **Lifecycle**: Plan -- **Category**: Analytics -- **Primary artifact**: Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria - -Write a SQL query from a natural-language description, optimized for the user's SQL dialect and use case. - -## Argument Hint - -`` - -## Usage - -```text -/write-query -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `sql generator`, `bigquery`, `postgres`, `mysql`, `schema diagram`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Understand the Request - -Parse the user's description to identify: -- Output columns. -- Filters: time ranges, segments, statuses, exclusions. -- Aggregations: counts, sums, averages, rates, distincts. -- Joins and required entities. -- Ordering. -- Limits, top-N, or sample requirements. -- Expected grain: one row per what. - -If the request is ambiguous, ask only for the missing detail that changes query correctness. - -### 2. Determine SQL Dialect - -If not known, ask which dialect they use: -- PostgreSQL, including Aurora, RDS, Supabase, Neon. -- Snowflake. -- BigQuery. -- Redshift. -- Databricks SQL. -- MySQL. -- SQL Server. -- DuckDB. -- SQLite. -- Other. - -Use `sql-queries` for dialect-specific syntax, date functions, semi-structured data, performance notes, and debugging. - -### 3. Discover Schema - -If a warehouse or schema tool is connected: -1. Search for relevant tables. -2. Inspect column names, types, and relationships. -3. Check partition, clustering, sort, or distribution keys. -4. Look for existing views or materialized views. - -If no warehouse is connected: -- Ask for table names, schema, or sample rows. -- If the schema is unknown, provide a query template with clearly marked placeholders. - -### 4. Write the Query - -Structure: -- Use CTEs for multi-step logic. -- Use one CTE per logical transformation or source. -- Name CTEs descriptively. -- Keep the final SELECT easy to scan. - -Performance: -- Avoid `SELECT *` in production queries. -- Filter early, especially on dates and partitions. -- Use partition filters for BigQuery/Databricks and clustering/sort-aware filters for Snowflake/Redshift. -- Use appropriate join types. -- Avoid correlated subqueries when joins or windows are clearer. -- Watch for many-to-many joins and potential row multiplication. -- Prefer approximate distinct functions only when accuracy tradeoffs are acceptable and stated. - -Readability: -- Add comments for non-obvious business logic. -- Use consistent formatting and indentation. -- Use meaningful table aliases. -- Put major clauses on their own lines. - -Correctness: -- Protect rate denominators with `NULLIF` or dialect-safe division. -- Define timezones and date boundaries. -- Deduplicate before aggregation when needed. -- Keep metric definitions explicit. - -### 5. Present the Query - -Provide: -1. Complete SQL code block. -2. Short explanation of each CTE or major section. -3. Performance notes and likely bottlenecks. -4. Modification suggestions for date range, granularity, dimensions, or filters. -5. Validation checks the user can run. - -### 6. Offer Execution or Review - -If a warehouse is connected, offer to run the query and inspect results. If the user will run it themselves, make the query copy-paste ready. - -## Output Template - -````markdown -## Query - -```sql --- SQL here -``` - -## How It Works -- `[cte_name]`: ... - -## Performance Notes -- ... - -## Validation Checks -- Row count before and after joins. -- Date range coverage. -- Duplicate key checks. -- Aggregate reconciliation. - -## Common Modifications -- To change time range: ... -- To group by another dimension: ... -```` - -## Examples - -- Count orders by status for the last 30 days. -- Cohort retention by signup month with activity at 1, 3, 6, and 12 months. -- Top 100 users by event count in the last 7 days from a large partitioned events table. - -## Rules - -- Do not invent exact table or column names when schema is unknown; use placeholders or ask for schema. -- If using assumptions, state them next to the query. -- For recurring queries, parameterize date ranges when the dialect supports it. -- For high-stakes analysis, recommend `validate-data` after results are produced. diff --git a/skills/write-query/SKILL.md.tmpl b/skills/write-query/SKILL.md.tmpl deleted file mode 100644 index 0d6cf90c..00000000 --- a/skills/write-query/SKILL.md.tmpl +++ /dev/null @@ -1,150 +0,0 @@ ---- -name: write-query -description: >- - Write optimized SQL for a specific dialect with best practices. Use when translating a natural - language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing - a large partitioned-table query, or getting Snowflake, BigQuery, Postgres, or other dialect syntax. ---- -# Write Query - -{{PRODUCTIZE_PREAMBLE}} - -Write a SQL query from a natural-language description, optimized for the user's SQL dialect and use case. - -## Argument Hint - -`` - -## Usage - -```text -/write-query -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `sql generator`, `bigquery`, `postgres`, `mysql`, `schema diagram`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Understand the Request - -Parse the user's description to identify: -- Output columns. -- Filters: time ranges, segments, statuses, exclusions. -- Aggregations: counts, sums, averages, rates, distincts. -- Joins and required entities. -- Ordering. -- Limits, top-N, or sample requirements. -- Expected grain: one row per what. - -If the request is ambiguous, ask only for the missing detail that changes query correctness. - -### 2. Determine SQL Dialect - -If not known, ask which dialect they use: -- PostgreSQL, including Aurora, RDS, Supabase, Neon. -- Snowflake. -- BigQuery. -- Redshift. -- Databricks SQL. -- MySQL. -- SQL Server. -- DuckDB. -- SQLite. -- Other. - -Use `sql-queries` for dialect-specific syntax, date functions, semi-structured data, performance notes, and debugging. - -### 3. Discover Schema - -If a warehouse or schema tool is connected: -1. Search for relevant tables. -2. Inspect column names, types, and relationships. -3. Check partition, clustering, sort, or distribution keys. -4. Look for existing views or materialized views. - -If no warehouse is connected: -- Ask for table names, schema, or sample rows. -- If the schema is unknown, provide a query template with clearly marked placeholders. - -### 4. Write the Query - -Structure: -- Use CTEs for multi-step logic. -- Use one CTE per logical transformation or source. -- Name CTEs descriptively. -- Keep the final SELECT easy to scan. - -Performance: -- Avoid `SELECT *` in production queries. -- Filter early, especially on dates and partitions. -- Use partition filters for BigQuery/Databricks and clustering/sort-aware filters for Snowflake/Redshift. -- Use appropriate join types. -- Avoid correlated subqueries when joins or windows are clearer. -- Watch for many-to-many joins and potential row multiplication. -- Prefer approximate distinct functions only when accuracy tradeoffs are acceptable and stated. - -Readability: -- Add comments for non-obvious business logic. -- Use consistent formatting and indentation. -- Use meaningful table aliases. -- Put major clauses on their own lines. - -Correctness: -- Protect rate denominators with `NULLIF` or dialect-safe division. -- Define timezones and date boundaries. -- Deduplicate before aggregation when needed. -- Keep metric definitions explicit. - -### 5. Present the Query - -Provide: -1. Complete SQL code block. -2. Short explanation of each CTE or major section. -3. Performance notes and likely bottlenecks. -4. Modification suggestions for date range, granularity, dimensions, or filters. -5. Validation checks the user can run. - -### 6. Offer Execution or Review - -If a warehouse is connected, offer to run the query and inspect results. If the user will run it themselves, make the query copy-paste ready. - -## Output Template - -````markdown -## Query - -```sql --- SQL here -``` - -## How It Works -- `[cte_name]`: ... - -## Performance Notes -- ... - -## Validation Checks -- Row count before and after joins. -- Date range coverage. -- Duplicate key checks. -- Aggregate reconciliation. - -## Common Modifications -- To change time range: ... -- To group by another dimension: ... -```` - -## Examples - -- Count orders by status for the last 30 days. -- Cohort retention by signup month with activity at 1, 3, 6, and 12 months. -- Top 100 users by event count in the last 7 days from a large partitioned events table. - -## Rules - -- Do not invent exact table or column names when schema is unknown; use placeholders or ask for schema. -- If using assumptions, state them next to the query. -- For recurring queries, parameterize date ranges when the dialect supports it. -- For high-stakes analysis, recommend `validate-data` after results are produced. diff --git a/skills/write-query/agents/openai.yaml b/skills/write-query/agents/openai.yaml deleted file mode 100644 index 2c2a7c5b..00000000 --- a/skills/write-query/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Write Query" - short_description: "Write optimized SQL for a specific dialect with best practices. Use when translating a natural language data need..." - brand_color: "#0F766E" - default_prompt: "Use $write-query with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/write-query/productize.json b/skills/write-query/productize.json deleted file mode 100644 index bd5a8000..00000000 --- a/skills/write-query/productize.json +++ /dev/null @@ -1,55 +0,0 @@ -{ - "title": "Write Query", - "category": "Analytics", - "tags": [ - "sql", - "query-writing", - "natural-language-to-sql", - "warehouse", - "optimization", - "dialects", - "write-query", - "write", - "query", - "data", - "reporting", - "optimized", - "specific", - "sql-generator" - ], - "lifecycle": "Plan", - "use_when": "Write optimized SQL for a specific dialect with best practices. Use when translating a natural language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a large partitioned-table query, or getting Snowflake, BigQuery, Postgres, or other dialect syntax.", - "do_not_use_when": "Do not use Write Query when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria", - "routing_signals": [ - "write-query", - "write", - "query", - "data", - "reporting", - "optimized", - "sql", - "specific", - "sql-generator", - "bigquery", - "postgres", - "mysql", - "schema-diagram", - "analytics" - ], - "framework_fit": "Write Query fits Analytics work in the Plan lifecycle when the user needs Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Write Query as generic Analytics advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Write Query when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $write-query to turn this write context into a decision-ready Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria.", - "expected_artifact": "Write Query delivery brief with scope, requirements, priorities, risks, and acceptance criteria" - } - ], - "references": [ - "references/pm-skills-main-merge.md" - ] -} diff --git a/skills/write-query/references/pm-skills-main-merge.md b/skills/write-query/references/pm-skills-main-merge.md deleted file mode 100644 index 8cc6198d..00000000 --- a/skills/write-query/references/pm-skills-main-merge.md +++ /dev/null @@ -1,94 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to strengthen SQL generation across dialects and schema interpretation from product analytics questions. - -## Routing Signals - -- sql generator -- bigquery -- postgres -- mysql -- schema diagram - -## pm-data-analytics/skills/sql-queries/SKILL.md - -## Purpose -Transform natural language requirements into optimized SQL queries across multiple database platforms. This skill helps product managers, analysts, and engineers generate accurate queries without manual syntax work. - -## How It Works - -### Step 1: Understand Your Database Schema -- If you provide a schema file (SQL, documentation, or diagram description), I will read and analyze it -- Extract table names, column definitions, data types, and relationships -- Identify primary keys, foreign keys, and indexing strategies - -### Step 2: Process Your Request -- Clarify the exact data you need to retrieve or analyze -- Confirm the SQL dialect (BigQuery, PostgreSQL, MySQL, Snowflake, etc.) -- Ask for any additional requirements (filters, aggregations, sorting) - -### Step 3: Generate Optimized Query -- Write efficient SQL that leverages your database structure -- Include comments explaining complex logic -- Add performance considerations for large datasets -- Provide alternative approaches if applicable - -### Step 4: Explain and Test -- Explain the query logic in plain English -- Suggest how to test or validate results -- Offer tips for performance optimization -- If you want, generate a test script or sample data - -## Usage Examples - -**Example 1: Query from Schema File** -``` -Upload your database_schema.sql file and say: -"Generate a query to find users who signed up in the last 30 days -and had at least 5 active sessions" -``` - -**Example 2: Query from Diagram Description** -``` -"Here's my database: Users table (id, email, created_at), Sessions table -(id, user_id, timestamp, duration). Generate a query for average session -duration per user in January 2026." -``` - -**Example 3: Complex Analysis Query** -``` -"Create a BigQuery query to analyze our revenue by region and customer tier, -including year-over-year growth rates." -``` - -## Key Capabilities - -- **Multi-Dialect Support**: Works with BigQuery, PostgreSQL, MySQL, Snowflake, SQL Server -- **File Reading**: Reads schema files, SQL dumps, and data documentation -- **Query Optimization**: Suggests indexes, partitioning, and performance improvements -- **Explanation**: Breaks down queries for learning and documentation -- **Testing**: Can generate test queries and sample data scripts -- **Script Execution**: Create executable SQL scripts for your database - -## Tips for Best Results - -1. **Provide context**: Share your database schema or structure -2. **Be specific**: Clearly describe what data you need and any filters -3. **Mention database**: Specify which SQL dialect you're using -4. **Include constraints**: Mention data volume, time ranges, and performance needs -5. **Request format**: Ask for the query result format if you need specific output - -## Output Format - -You'll receive: -- **SQL Query**: Production-ready SQL code with comments -- **Explanation**: What the query does and how it works -- **Performance Notes**: Optimization tips and considerations -- **Test Script** (if requested): Sample data and validation queries - ---- - -### Further Reading - -- [The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels for PMs](https://www.productcompass.pm/p/the-product-analytics-playbook-aarrr) -- [How to Become a Technology-Literate PM](https://www.productcompass.pm/p/how-to-become-a-technology-literate) diff --git a/skills/write-spec/SKILL.md b/skills/write-spec/SKILL.md deleted file mode 100644 index 8f5b5cc5..00000000 --- a/skills/write-spec/SKILL.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -name: write-spec -description: >- - Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague - idea into a structured document, scoping goals and non-goals, defining success metrics and - acceptance criteria, or breaking a big ask into phases. ---- - - - -# Write Spec - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `write-spec` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Feature spec or PRD with scope, success metrics, and acceptance criteria - -Write a feature specification or product requirements document. - -## Argument Hint - -`` - -## Usage - -```text -/write-spec $ARGUMENTS -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `create prd`, `8-section prd`, `feature spec`, `release planning`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Understand the Feature - -Accept a feature name, problem statement, user request, or vague idea. - -Ask conversationally for the most important missing context: -- User problem and affected segment. -- Success metrics. -- Constraints, dependencies, deadlines. -- Prior attempts or related solutions. - -### 2. Pull Context - -If connected, search project tracker, docs, research, design files, and meeting notes for related work, requirements, mockups, decisions, and dependencies. - -If tools are not connected, proceed from user-provided context and state assumptions. - -### 3. Generate PRD - -Include: -- **Problem Statement**: 2-3 sentences with user, pain, frequency, and impact. -- **Goals**: 3-5 measurable outcomes. -- **Non-Goals**: 3-5 out-of-scope items with rationale. -- **User Stories**: "As a [user], I want [capability], so that [benefit]." -- **Requirements**: P0, P1, P2 with acceptance criteria. -- **Success Metrics**: leading and lagging indicators with targets and measurement method. -- **Open Questions**: tagged by owner and blocking status. -- **Timeline Considerations**: hard deadlines, dependencies, phasing. - -### 4. Acceptance Criteria - -Use Given/When/Then or checklist format. Cover: -- Happy path. -- Error states. -- Empty states. -- Boundary conditions. -- Negative cases. - -### 5. Scope Rules - -- Be opinionated about v1 scope. -- If everything is P0, challenge it. -- Require scope addition to come with scope removal or timeline extension. -- Separate v1 from future considerations. -- Keep requirements behavior-focused, not implementation-prescriptive unless necessary. - -## Output Rules - -Use clear markdown headers and tables where helpful. Keep the spec skimmable. Open questions must be genuinely unresolved. diff --git a/skills/write-spec/SKILL.md.tmpl b/skills/write-spec/SKILL.md.tmpl deleted file mode 100644 index 01392e32..00000000 --- a/skills/write-spec/SKILL.md.tmpl +++ /dev/null @@ -1,77 +0,0 @@ ---- -name: write-spec -description: >- - Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague - idea into a structured document, scoping goals and non-goals, defining success metrics and - acceptance criteria, or breaking a big ask into phases. ---- -# Write Spec - -{{PRODUCTIZE_PREAMBLE}} - -Write a feature specification or product requirements document. - -## Argument Hint - -`` - -## Usage - -```text -/write-spec $ARGUMENTS -``` - -## PM Skills Main Merge - -Load `references/pm-skills-main-merge.md` when the request mentions `create prd`, `8-section prd`, `feature spec`, `release planning`. Use the PM source material to sharpen this existing Productize skill rather than routing to a duplicate skill. - -## Workflow - -### 1. Understand the Feature - -Accept a feature name, problem statement, user request, or vague idea. - -Ask conversationally for the most important missing context: -- User problem and affected segment. -- Success metrics. -- Constraints, dependencies, deadlines. -- Prior attempts or related solutions. - -### 2. Pull Context - -If connected, search project tracker, docs, research, design files, and meeting notes for related work, requirements, mockups, decisions, and dependencies. - -If tools are not connected, proceed from user-provided context and state assumptions. - -### 3. Generate PRD - -Include: -- **Problem Statement**: 2-3 sentences with user, pain, frequency, and impact. -- **Goals**: 3-5 measurable outcomes. -- **Non-Goals**: 3-5 out-of-scope items with rationale. -- **User Stories**: "As a [user], I want [capability], so that [benefit]." -- **Requirements**: P0, P1, P2 with acceptance criteria. -- **Success Metrics**: leading and lagging indicators with targets and measurement method. -- **Open Questions**: tagged by owner and blocking status. -- **Timeline Considerations**: hard deadlines, dependencies, phasing. - -### 4. Acceptance Criteria - -Use Given/When/Then or checklist format. Cover: -- Happy path. -- Error states. -- Empty states. -- Boundary conditions. -- Negative cases. - -### 5. Scope Rules - -- Be opinionated about v1 scope. -- If everything is P0, challenge it. -- Require scope addition to come with scope removal or timeline extension. -- Separate v1 from future considerations. -- Keep requirements behavior-focused, not implementation-prescriptive unless necessary. - -## Output Rules - -Use clear markdown headers and tables where helpful. Keep the spec skimmable. Open questions must be genuinely unresolved. diff --git a/skills/write-spec/agents/openai.yaml b/skills/write-spec/agents/openai.yaml deleted file mode 100644 index 2c9fafc6..00000000 --- a/skills/write-spec/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Write Spec" - short_description: "Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea into a..." - brand_color: "#4F46E5" - default_prompt: "Use $write-spec with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/write-spec/productize.json b/skills/write-spec/productize.json deleted file mode 100644 index d615985f..00000000 --- a/skills/write-spec/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Write Spec", - "category": "Delivery", - "tags": [ - "prd", - "spec", - "requirements", - "acceptance-criteria", - "scope", - "user-stories", - "write-spec", - "write", - "business", - "feature", - "problem", - "create-prd", - "8-section-prd", - "feature-spec" - ], - "lifecycle": "Plan", - "use_when": "Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea into a structured document, scoping goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into phases.", - "do_not_use_when": "Do not use Write Spec when the request is mainly a different lifecycle artifact; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Feature spec or PRD with scope, success metrics, and acceptance criteria", - "routing_signals": [ - "write-spec", - "write", - "spec", - "business", - "feature", - "prd", - "problem", - "create-prd", - "8-section-prd", - "feature-spec", - "release-planning", - "delivery" - ], - "framework_fit": "Appropriate when a vague feature idea or problem statement needs to become a product spec before design or build handoff. PM-skills-main merge: Use the PM source to sharpen PRD structure around problem, objectives, segments, value proposition, solution, scope, and release planning.", - "failure_modes": [ - "Produces Feature spec or PRD with scope, success metrics, and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Write Spec as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Write Spec when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $write-spec to turn this write context into a decision-ready Feature spec or PRD with scope, success metrics, and acceptance criteria.", - "expected_artifact": "Feature spec or PRD with scope, success metrics, and acceptance criteria" - } - ], - "references": [ - "references/pm-skills-main-merge.md" - ] -} diff --git a/skills/write-spec/references/pm-skills-main-merge.md b/skills/write-spec/references/pm-skills-main-merge.md deleted file mode 100644 index fbb9df1e..00000000 --- a/skills/write-spec/references/pm-skills-main-merge.md +++ /dev/null @@ -1,92 +0,0 @@ -# PM Skills Main Merge Notes - -Use the PM source to sharpen PRD structure around problem, objectives, segments, value proposition, solution, scope, and release planning. - -## Routing Signals - -- create prd -- 8-section prd -- feature spec -- release planning - -## pm-execution/skills/create-prd/SKILL.md - -## Purpose - -You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development. - -## Context - -A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders. - -## Instructions - -1. **Gather Information**: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights. - -2. **Think Step by Step**: Before writing, analyze: - - What problem are we solving? - - Who are we solving it for? - - How will we measure success? - - What are our constraints and assumptions? - -3. **Apply the PRD Template**: Create a document with these 8 sections: - - **1. Summary** (2-3 sentences) - - What is this document about? - - **2. Contacts** - - Name, role, and comment for key stakeholders - - **3. Background** - - Context: What is this initiative about? - - Why now? Has something changed? - - Is this something that just recently became possible? - - **4. Objective** - - What's the objective? Why does it matter? - - How will it benefit the company and customers? - - How does it align with vision and strategy? - - Key Results: How will you measure success? (Use SMART OKR format) - - **5. Market Segment(s)** - - For whom are we building this? - - What constraints exist? - - Note: Markets are defined by people's problems/jobs, not demographics - - **6. Value Proposition(s)** - - What customer jobs/needs are we addressing? - - What will customers gain? - - Which pains will they avoid? - - Which problems do we solve better than competitors? - - Consider the Value Curve framework - - **7. Solution** - - 7.1 UX/Prototypes (wireframes, user flows) - - 7.2 Key Features (detailed feature descriptions) - - 7.3 Technology (optional, only if relevant) - - 7.4 Assumptions (what we believe but haven't proven) - - **8. Release** - - How long could it take? - - What goes in the first version vs. future versions? - - Avoid exact dates; use relative timeframes - -4. **Use Accessible Language**: Write for a primary school graduate. Avoid jargon. Use clear, short sentences. - -5. **Structure Output**: Present the PRD as a well-formatted markdown document with clear headings and sections. - -6. **Save the Output**: If the PRD is substantial (which it will be), save it as a markdown document in the format: `PRD-[product-name].md` - -## Notes - -- Be specific and data-driven where possible -- Link each section back to the overall strategy -- Flag assumptions clearly so the team can validate them -- Keep the document concise but complete - ---- - -### Further Reading - -- [How to Write a Product Requirements Document? The Best PRD Template.](https://www.productcompass.pm/p/prd-template) -- [A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)](https://www.productcompass.pm/p/ai-prd-template) diff --git a/skills/writing-plans/SKILL.md b/skills/writing-plans/SKILL.md deleted file mode 100644 index b9cf2848..00000000 --- a/skills/writing-plans/SKILL.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -name: writing-plans -description: >- - Create comprehensive implementation plans with bite-sized tasks. Use when you have requirements - before touching code. ---- - - - -# Writing Plans - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `writing-plans` -- **Lifecycle**: Build With AI -- **Category**: AI Execution -- **Primary artifact**: Writing Plans AI-builder handoff with implementation scope, verification plan, and risks - -Use when you have requirements for a multi-step task, before touching code. - -## Overview - -Write comprehensive implementation plans assuming the reader has zero context. Document everything: which files to touch, code snippets, testing steps, verification commands. Break into bite-sized tasks. - -## Bite-Sized Task Granularity - -Each step is one action (2-5 minutes): -- "Write the failing test" - step -- "Run it to make sure it fails" - step -- "Implement the minimal code to make the test pass" - step -- "Run the tests and make sure they pass" - step -- "Commit" - step - -## Plan Document Header - -Every plan should start with: - -```markdown -# [Feature Name] Implementation Plan - -**Goal:** [One sentence describing what this builds] - -**Architecture:** [2-3 sentences about approach] - -**Tech Stack:** [Key technologies/libraries] - ---- -``` - -## Task Structure - -```markdown -### Task N: [Component Name] - -**Files:** -- Create: `exact/path/to/file.py` -- Modify: `exact/path/to/existing.py:123-145` -- Test: `tests/exact/path/to/test.py` - -**Step 1: Write the failing test** - -```python -def test_specific_behavior(): - result = function(input) - assert result == expected -``` - -**Step 2: Run test to verify it fails** - -Run: `pytest tests/path/test.py::test_name -v` -Expected: FAIL with "function not defined" - -**Step 3: Write minimal implementation** - -```python -def function(input): - return expected -``` - -**Step 4: Run test to verify it passes** - -Run: `pytest tests/path/test.py::test_name -v` -Expected: PASS - -**Step 5: Commit** - -```bash -git add tests/path/test.py src/path/file.py -git commit -m "feat: add specific feature" -``` -``` - -## Remember - -- Exact file paths always -- Complete code in plan (not "add validation") -- Exact commands with expected output -- DRY, YAGNI, TDD, frequent commits - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/writing-plans/SKILL.md.tmpl b/skills/writing-plans/SKILL.md.tmpl deleted file mode 100644 index 967e50c2..00000000 --- a/skills/writing-plans/SKILL.md.tmpl +++ /dev/null @@ -1,98 +0,0 @@ ---- -name: writing-plans -description: >- - Create comprehensive implementation plans with bite-sized tasks. Use when you have requirements - before touching code. ---- -# Writing Plans - -{{PRODUCTIZE_PREAMBLE}} - -Use when you have requirements for a multi-step task, before touching code. - -## Overview - -Write comprehensive implementation plans assuming the reader has zero context. Document everything: which files to touch, code snippets, testing steps, verification commands. Break into bite-sized tasks. - -## Bite-Sized Task Granularity - -Each step is one action (2-5 minutes): -- "Write the failing test" - step -- "Run it to make sure it fails" - step -- "Implement the minimal code to make the test pass" - step -- "Run the tests and make sure they pass" - step -- "Commit" - step - -## Plan Document Header - -Every plan should start with: - -```markdown -# [Feature Name] Implementation Plan - -**Goal:** [One sentence describing what this builds] - -**Architecture:** [2-3 sentences about approach] - -**Tech Stack:** [Key technologies/libraries] - ---- -``` - -## Task Structure - -```markdown -### Task N: [Component Name] - -**Files:** -- Create: `exact/path/to/file.py` -- Modify: `exact/path/to/existing.py:123-145` -- Test: `tests/exact/path/to/test.py` - -**Step 1: Write the failing test** - -```python -def test_specific_behavior(): - result = function(input) - assert result == expected -``` - -**Step 2: Run test to verify it fails** - -Run: `pytest tests/path/test.py::test_name -v` -Expected: FAIL with "function not defined" - -**Step 3: Write minimal implementation** - -```python -def function(input): - return expected -``` - -**Step 4: Run test to verify it passes** - -Run: `pytest tests/path/test.py::test_name -v` -Expected: PASS - -**Step 5: Commit** - -```bash -git add tests/path/test.py src/path/file.py -git commit -m "feat: add specific feature" -``` -``` - -## Remember - -- Exact file paths always -- Complete code in plan (not "add validation") -- Exact commands with expected output -- DRY, YAGNI, TDD, frequent commits - -## When to Use - -Use this skill when the task directly matches the workflow described above. - -## When Not to Use - -Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response. diff --git a/skills/writing-plans/agents/openai.yaml b/skills/writing-plans/agents/openai.yaml deleted file mode 100644 index 49a1917d..00000000 --- a/skills/writing-plans/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Writing Plans" - short_description: "Create comprehensive implementation plans with bite-sized tasks. Use when you have requirements before touching code." - brand_color: "#334155" - default_prompt: "Use $writing-plans with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/writing-plans/productize.json b/skills/writing-plans/productize.json deleted file mode 100644 index d84eb981..00000000 --- a/skills/writing-plans/productize.json +++ /dev/null @@ -1,47 +0,0 @@ -{ - "title": "Writing Plans", - "category": "AI Execution", - "tags": [ - "implementation-planning", - "task-breakdown", - "technical-planning", - "tdd", - "verification", - "engineering", - "writing-plans", - "writing", - "plans", - "technical", - "create", - "comprehensive", - "implementation", - "bite" - ], - "lifecycle": "Build With AI", - "use_when": "Create comprehensive implementation plans with bite-sized tasks. Use when you have requirements before touching code.", - "do_not_use_when": "Do not use Writing Plans when the request is mainly market strategy, research synthesis, finance modeling, or executive communication; route to the narrower Productize skill that owns that artifact instead. Do not use it when the user lacks enough context to distinguish facts, assumptions, and decision risk.", - "output_artifact": "Writing Plans AI-builder handoff with implementation scope, verification plan, and risks", - "routing_signals": [ - "writing-plans", - "writing", - "plans", - "technical", - "create", - "comprehensive", - "implementation", - "bite", - "execution" - ], - "framework_fit": "Writing Plans fits AI Execution work in the Build With AI lifecycle when the user needs Writing Plans AI-builder handoff with implementation scope, verification plan, and risks and has enough product context to make tradeoffs explicit. Use it to produce a decision-ready artifact, not a framework tour.", - "failure_modes": [ - "Produces Writing Plans AI-builder handoff with implementation scope, verification plan, and risks without tying recommendations to the user's Build With AI stage, evidence, and decision pressure.", - "Treats Writing Plans as generic AI Execution advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Writing Plans when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $writing-plans to turn this writing context into a decision-ready Writing Plans AI-builder handoff with implementation scope, verification plan, and risks.", - "expected_artifact": "Writing Plans AI-builder handoff with implementation scope, verification plan, and risks" - } - ] -} diff --git a/skills/wwas/SKILL.md b/skills/wwas/SKILL.md deleted file mode 100644 index 48d3719b..00000000 --- a/skills/wwas/SKILL.md +++ /dev/null @@ -1,151 +0,0 @@ ---- -name: wwas -description: >- - Why-What-Acceptance. Use when writing backlog items in Why-What-Acceptance format, - breaking features into independent valuable work, or adding strategic context to - delivery items. ---- - - - -# Why-What-Acceptance - -## Productize Preamble - -Before producing the artifact, implementation step, or code change, classify the work: - -- **User/persona**: founder, product leader, AI PM, AI builder, stakeholder, or mixed/unknown. -- **Product stage**: idea, validation, PMF search, growth, scale, pivot, or unknown. -- **Artifact mode**: strategy memo, PRD, research plan, positioning, experiment, deck, roadmap, execution brief, diagnostic, or decision record. -- **Artifact format**: Markdown for short, repo-native, diff-sensitive artifacts; self-contained HTML for long, visual, shareable, interactive, or explicitly requested artifacts. -- **Evidence standard**: what is known, assumed, missing, and risky. -- **Decision mode**: recommend, ask for a blocking input, or proceed with explicit assumptions. - -Operating rules: - -1. Do not produce generic product strategy filler. Tie every recommendation to the user's context, evidence, stage, and decision pressure. -2. Separate facts from assumptions. Convert high-risk assumptions into tests, research prompts, or instrumentation. -3. Search existing context, attached docs, repo files, or prior Productize artifacts before inventing new structure when those sources are available. -4. Ask only for inputs that materially change the output. If the next step is obvious, proceed and state assumptions. -5. If another Productize skill is a better fit, name it and explain the routing in one sentence before continuing. -6. Enforce the output contract for this skill. Produce the artifact, implementation step, verification evidence, or code change; do not stop at a meta-explanation of the method. -7. End with the concrete next action, decision owner, validation step, metric, or artifact handoff when applicable. -8. Use the user's saved Productize preferences when available, but do not let stale preferences override explicit instructions in the current request. -9. If you must ask a blocking question, use this compact format: `AskUserQuestion: Why it matters: `. -10. Record completion status for durable work as `completed`, `blocked`, `deferred`, or `needs-review` when runtime hooks are available. - -Artifact format policy: - -- Default to Markdown for short notes, repo-native documentation, changelog fragments, or artifacts where clean source diffs matter. -- Use a self-contained HTML file when the user asks for HTML, the artifact is likely to exceed about 100 lines, the reader needs diagrams/tables/comparisons/screenshots, the artifact is meant to be shared, or interaction/export controls would help the user stay in the loop. -- Route by product job first, then choose the format. Do not create a generic HTML workflow when a Productize playbook, gate, or routed skill owns the work. -- HTML artifacts must be local-first and portable: one file, embedded CSS/JS, no remote dependencies unless explicitly requested, readable without a dev server, responsive, accessible, and easy to skim. -- Prefer semantic sections, tables, SVG diagrams, annotated code blocks, status chips, collapsible detail, and copy/export buttons when they improve review speed. Avoid decorative complexity that hides the decision. -- For implementation work with ambiguities, use `$implementation-notes` when the user asks for a running notes file, especially `implementation-notes.html` or `implementation-notes.md`. - -Runtime hooks, if available: - -- Use `productize-workflow start ""` at the beginning of durable product work; it restores context, routes the request, records the session, and returns the required artifact contract. -- Use `productize-workflow complete --id --status completed|blocked|deferred|needs-review --artifact-type --summary ` before ending durable product work; it records the artifact, saves context, and logs completion status. -- Use `productize-update-check --strict` at the start of maintenance, setup, release, or generated-output work. -- Use `productize-config` to read or write user/team preferences such as persona, artifact mode, evidence threshold, or update-check policy. -- Use `productize-session-log` to record important workflow decisions. -- Use `productize-artifact-log` when a durable artifact is produced. -- Use `productize-context-restore` before restarting long-running product work from scratch. -- Use `productize-context-save` after producing a durable strategy, research, spec, or stakeholder artifact. -- Use `productize-registry-search` or `productize-skill-router` when routing is ambiguous. -- Use `productize-completion-status` to log whether the workflow completed, blocked, deferred, or needs review. - -Telemetry standard: - -- Keep telemetry local by default in `.productize/` or `PRODUCTIZE_STATE_DIR`. -- Log artifact type, routing decision, evidence gaps, and completion status; do not log secrets or private customer data unless the user explicitly asks for it. - -Current skill metadata: - -- **Skill**: `wwas` -- **Lifecycle**: Plan -- **Category**: Delivery -- **Primary artifact**: Why-What-Acceptance backlog items with strategic context and acceptance criteria - -Use when writing backlog items in Why-What-Acceptance format, breaking features into independent valuable work, or adding strategic context to delivery items. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: Build With AI -- **Primary artifact**: Why-What-Acceptance backlog items with strategic context and acceptance criteria -- **Source method**: pm-skills-main/pm-execution/skills/wwas/SKILL.md - -## Method - -Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context. - -**Use when:** Writing backlog items, creating product increments, breaking features into work items, or communicating strategic intent to teams. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$FEATURE`: The new feature or capability -- `$DESIGN`: Link to design files (Figma, Miro, etc.) -- `$ASSUMPTIONS`: Key assumptions and strategic context - -## Step-by-Step Process - -1. **Define the strategic Why** - Connect work to business and team objectives -2. **Describe the What** - Keep descriptions concise, reference designs -3. **Write Acceptance Criteria** - High-level, not detailed specifications -4. **Ensure independence** - Items can be developed in any order -5. **Keep items negotiable** - Invite team conversation, not constraints -6. **Make items valuable** - Each delivers measurable user or business value -7. **Ensure testability** - Outcomes are observable and verifiable -8. **Size appropriately** - Small enough for one sprint estimate - -## Item Template - -**Title:** [What will be delivered] - -**Why:** [1-2 sentences connecting to strategic context and team objectives] - -**What:** [Short description and design link. 1-2 paragraphs maximum. A reminder of discussion, not detailed specification.] - -**Acceptance Criteria:** -- [Observable outcome 1] -- [Observable outcome 2] -- [Observable outcome 3] -- [Observable outcome 4] - -## Example WWA Item - -**Title:** Implement Real-Time Spending Tracker - -**Why:** Users need immediate feedback on spending to make conscious budget decisions. This directly supports our goal to improve financial awareness and reduce overspending. - -**What:** Add a real-time spending tracker that updates as users log expenses. The tracker displays their current week's spending against their set budget. Designs available in [Figma link]. This is a reminder of our discussions - detailed specifications will emerge during development conversations with the team. - -**Acceptance Criteria:** -- Spending totals update within 2 seconds of logging an expense -- Budget progress is visually indicated with a progress bar -- Users can see remaining budget amount at a glance -- System handles multiple expense categories correctly - -## Output Deliverables - -- Complete set of backlog items for the feature -- Each item includes Why, What, and Acceptance Criteria sections -- Items are independent and deliverable in any order -- Items are sized for estimation and completion in one sprint -- Strategic context is clear for team decision-making -- Design references are included for implementation guidance - ---- - -### Further Reading - -- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/wwas/SKILL.md.tmpl b/skills/wwas/SKILL.md.tmpl deleted file mode 100644 index 3d740454..00000000 --- a/skills/wwas/SKILL.md.tmpl +++ /dev/null @@ -1,92 +0,0 @@ ---- -name: wwas -description: >- - Why-What-Acceptance. Use when writing backlog items in Why-What-Acceptance format, - breaking features into independent valuable work, or adding strategic context to - delivery items. ---- -# Why-What-Acceptance - -{{PRODUCTIZE_PREAMBLE}} - -Use when writing backlog items in Why-What-Acceptance format, breaking features into independent valuable work, or adding strategic context to delivery items. - -## Productize Contract - -- **Primary lifecycle**: Plan -- **Supporting lifecycle**: Build With AI -- **Primary artifact**: Why-What-Acceptance backlog items with strategic context and acceptance criteria -- **Source method**: pm-skills-main/pm-execution/skills/wwas/SKILL.md - -## Method - -Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context. - -**Use when:** Writing backlog items, creating product increments, breaking features into work items, or communicating strategic intent to teams. - -**Arguments:** -- `$PRODUCT`: The product or system name -- `$FEATURE`: The new feature or capability -- `$DESIGN`: Link to design files (Figma, Miro, etc.) -- `$ASSUMPTIONS`: Key assumptions and strategic context - -## Step-by-Step Process - -1. **Define the strategic Why** - Connect work to business and team objectives -2. **Describe the What** - Keep descriptions concise, reference designs -3. **Write Acceptance Criteria** - High-level, not detailed specifications -4. **Ensure independence** - Items can be developed in any order -5. **Keep items negotiable** - Invite team conversation, not constraints -6. **Make items valuable** - Each delivers measurable user or business value -7. **Ensure testability** - Outcomes are observable and verifiable -8. **Size appropriately** - Small enough for one sprint estimate - -## Item Template - -**Title:** [What will be delivered] - -**Why:** [1-2 sentences connecting to strategic context and team objectives] - -**What:** [Short description and design link. 1-2 paragraphs maximum. A reminder of discussion, not detailed specification.] - -**Acceptance Criteria:** -- [Observable outcome 1] -- [Observable outcome 2] -- [Observable outcome 3] -- [Observable outcome 4] - -## Example WWA Item - -**Title:** Implement Real-Time Spending Tracker - -**Why:** Users need immediate feedback on spending to make conscious budget decisions. This directly supports our goal to improve financial awareness and reduce overspending. - -**What:** Add a real-time spending tracker that updates as users log expenses. The tracker displays their current week's spending against their set budget. Designs available in [Figma link]. This is a reminder of our discussions - detailed specifications will emerge during development conversations with the team. - -**Acceptance Criteria:** -- Spending totals update within 2 seconds of logging an expense -- Budget progress is visually indicated with a progress bar -- Users can see remaining budget amount at a glance -- System handles multiple expense categories correctly - -## Output Deliverables - -- Complete set of backlog items for the feature -- Each item includes Why, What, and Acceptance Criteria sections -- Items are independent and deliverable in any order -- Items are sized for estimation and completion in one sprint -- Strategic context is clear for team decision-making -- Design references are included for implementation guidance - ---- - -### Further Reading - -- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories) - -## Productize Output Rules - -- Produce the artifact named in the Productize contract, not a generic framework summary. -- Separate known facts, assumptions, missing evidence, and risky leaps before recommending. -- Convert uncertain claims into validation steps, metrics, owner decisions, or launch/readout checks. -- If the PM source method conflicts with Productize evidence standards, keep the Productize standard. diff --git a/skills/wwas/agents/openai.yaml b/skills/wwas/agents/openai.yaml deleted file mode 100644 index 605c19f2..00000000 --- a/skills/wwas/agents/openai.yaml +++ /dev/null @@ -1,8 +0,0 @@ -interface: - display_name: "Why-What-Acceptance" - short_description: "Why-What-Acceptance. Use when writing backlog items in Why-What-Acceptance format, breaking features into..." - brand_color: "#4F46E5" - default_prompt: "Use $wwas with my product context." - -policy: - allow_implicit_invocation: true diff --git a/skills/wwas/productize.json b/skills/wwas/productize.json deleted file mode 100644 index c3b734ad..00000000 --- a/skills/wwas/productize.json +++ /dev/null @@ -1,53 +0,0 @@ -{ - "title": "Why-What-Acceptance", - "category": "Delivery", - "lifecycle": "Plan", - "tags": [ - "wwas", - "wwa", - "why-what-acceptance", - "backlog-items", - "acceptance-criteria", - "strategic-context", - "build-with-ai", - "why", - "what", - "acceptance", - "project", - "management", - "use", - "delivery" - ], - "use_when": "Use when writing backlog items in Why-What-Acceptance format, breaking features into independent valuable work, or adding strategic context to delivery items.", - "do_not_use_when": "Do not use when the user explicitly wants classic user stories, job stories, or a full PRD.", - "output_artifact": "Why-What-Acceptance backlog items with strategic context and acceptance criteria", - "routing_signals": [ - "wwas", - "wwa", - "why-what-acceptance", - "backlog-items", - "acceptance-criteria", - "strategic-context", - "when", - "writing", - "backlog", - "items", - "what", - "acceptance", - "format", - "breaking" - ], - "framework_fit": "Best when delivery teams need backlog items that preserve why the work matters, what must change, and how acceptance will be judged.", - "failure_modes": [ - "Produces Why-What-Acceptance backlog items with strategic context and acceptance criteria without tying recommendations to the user's Plan stage, evidence, and decision pressure.", - "Treats Why-What-Acceptance as generic Delivery advice instead of naming assumptions, missing inputs, risks, and the next validation step.", - "Fails to route away from Why-What-Acceptance when another Productize skill owns the requested artifact more directly." - ], - "examples": [ - { - "prompt": "Use $wwas to turn this wwa context into a decision-ready Why-What-Acceptance backlog items with strategic context and acceptance criteria.", - "expected_artifact": "Why-What-Acceptance backlog items with strategic context and acceptance criteria" - } - ], - "imported_from": "pm-skills-main/pm-execution/skills/wwas/SKILL.md" -} diff --git a/test/dogfood.test.mjs b/test/dogfood.test.mjs deleted file mode 100644 index 74e7a885..00000000 --- a/test/dogfood.test.mjs +++ /dev/null @@ -1,59 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync, readFileSync } from "node:fs"; -import path from "node:path"; -import { routeProductizeSkills } from "../bin/productize-routing.mjs"; -import { readAllSkills, repoRoot, skillsRoot } from "../scripts/lib/productize.mjs"; - -const dogfoodDir = path.join(skillsRoot, "dogfood"); -const templatePath = path.join(dogfoodDir, "SKILL.md.tmpl"); -const manifestPath = path.join(dogfoodDir, "productize.json"); -const taxonomyPath = path.join(dogfoodDir, "references", "issue-taxonomy.md"); -const reportTemplatePath = path.join(dogfoodDir, "templates", "dogfood-report-template.md"); - -for (const file of [templatePath, manifestPath, taxonomyPath, reportTemplatePath]) { - assert.ok(existsSync(file), `Missing dogfood file: ${path.relative(repoRoot, file)}`); -} - -const skillTemplate = readFileSync(templatePath, "utf8"); -assert.match(skillTemplate, /Check the console after every navigation and every significant interaction/); -assert.match(skillTemplate, /Screenshots\/Evidence/); -assert.match(skillTemplate, /Pages Tested/); -assert.match(skillTemplate, /Flows Tested/); -assert.match(skillTemplate, /Severity Table/); -assert.match(skillTemplate, /Blockers/); - -const taxonomy = readFileSync(taxonomyPath, "utf8"); -for (const severity of ["P0", "P1", "P2", "P3"]) { - assert.match(taxonomy, new RegExp(`\\b${severity}\\b`), `taxonomy should define ${severity}`); -} -for (const category of ["Functional", "Visual", "Accessibility", "Console", "UX", "Content", "Performance", "Data"]) { - assert.match(taxonomy, new RegExp(`### ${category}\\b`), `taxonomy should define ${category}`); -} - -const reportTemplate = readFileSync(reportTemplatePath, "utf8"); -for (const section of [ - "Pages Tested", - "Flows Tested", - "Console Errors", - "Screenshots / Evidence", - "Severity Table", - "Blockers", -]) { - assert.match(reportTemplate, new RegExp(section.replace("/", "\\/")), `report template should include ${section}`); -} - -const qaTemplate = readFileSync(path.join(skillsRoot, "qa", "SKILL.md.tmpl"), "utf8"); -const releaseTemplate = readFileSync(path.join(skillsRoot, "release", "SKILL.md.tmpl"), "utf8"); -const operateTemplate = readFileSync(path.join(skillsRoot, "operate", "SKILL.md.tmpl"), "utf8"); -assert.match(qaTemplate, /\$dogfood/); -assert.match(releaseTemplate, /\$dogfood/); -assert.match(operateTemplate, /\$dogfood/); - -const routes = routeProductizeSkills( - "Dogfood this local web app and test http://localhost:3000 end-to-end with screenshots and console checks.", - readAllSkills(), - 5, -); -assert.equal(routes[0]?.skill.skillName, "dogfood"); - -console.log("Dogfood skill tests passed."); diff --git a/test/eval-runner.test.mjs b/test/eval-runner.test.mjs deleted file mode 100644 index 73a408fe..00000000 --- a/test/eval-runner.test.mjs +++ /dev/null @@ -1,86 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync, mkdtempSync, readdirSync, readFileSync, rmSync } from "node:fs"; -import { spawnSync } from "node:child_process"; -import os from "node:os"; -import path from "node:path"; -import { repoRoot } from "../scripts/lib/productize.mjs"; - -const tmpRoot = mkdtempSync(path.join(os.tmpdir(), "productize-eval-runner-test-")); - -try { - const reportDir = path.join(tmpRoot, "llm-report"); - const result = spawnSync( - process.execPath, - ["scripts/eval-productize.mjs", "--llm-only", "--llm-required", "--report-dir", reportDir], - { - cwd: repoRoot, - encoding: "utf8", - env: { - ...process.env, - PRODUCTIZE_LLM_EVAL_COMMAND: `${process.execPath} test/fixtures/fake-llm-eval.mjs {prompt}`, - PRODUCTIZE_LLM_INPUT_COST_PER_1K: "0.001", - PRODUCTIZE_LLM_OUTPUT_COST_PER_1K: "0.002", - }, - }, - ); - const output = `${result.stdout || ""}${result.stderr || ""}`; - assert.equal(result.status, 0, output); - - const summaryPath = path.join(reportDir, "summary.json"); - const jsonlPath = path.join(reportDir, "results.jsonl"); - const markdownPath = path.join(reportDir, "summary.md"); - const artifactsPath = path.join(reportDir, "artifacts"); - assert.ok(existsSync(summaryPath), "summary.json should exist"); - assert.ok(existsSync(jsonlPath), "results.jsonl should exist"); - assert.ok(existsSync(markdownPath), "summary.md should exist"); - assert.ok(existsSync(artifactsPath), "artifacts directory should exist"); - - const summary = JSON.parse(readFileSync(summaryPath, "utf8")); - assert.equal(summary.failed, 0); - assert.equal(summary.cases, 10); - assert.ok(summary.score > 0); - assert.ok(summary.max_score >= summary.score); - assert.ok(summary.estimated_llm_cost_usd > 0); - assert.ok(summary.estimated_llm_input_tokens > 0); - assert.ok(summary.estimated_llm_output_tokens > 0); - assert.ok(summary.by_suite["llm:llm-cases.json"]); - - const resultLines = readFileSync(jsonlPath, "utf8").trim().split("\n").map((line) => JSON.parse(line)); - assert.equal(resultLines.length, summary.cases); - assert.ok(resultLines.every((line) => line.kind === "llm")); - assert.ok(resultLines.every((line) => line.metrics.estimated_cost_usd > 0)); - assert.ok(resultLines.every((line) => line.artifact_path)); - - const artifactFiles = readdirSync(artifactsPath).filter((file) => file.endsWith(".json")); - assert.equal(artifactFiles.length, summary.cases); - - const markdown = readFileSync(markdownPath, "utf8"); - assert.match(markdown, /Productize Eval Report/); - assert.match(markdown, /Estimated LLM cost/); - - const report = spawnSync(process.execPath, ["scripts/report-eval-results.mjs", reportDir], { - cwd: repoRoot, - encoding: "utf8", - }); - assert.equal(report.status, 0, `${report.stdout || ""}${report.stderr || ""}`); - assert.match(report.stdout, /Productize Eval Report/); - assert.match(report.stdout, /10/); - - const noCostDefaultReport = path.join(tmpRoot, "default-report"); - const noCostDefault = spawnSync(process.execPath, ["scripts/eval-productize.mjs", "--report-dir", noCostDefaultReport], { - cwd: repoRoot, - encoding: "utf8", - env: { - ...process.env, - PRODUCTIZE_LLM_EVAL_COMMAND: `${process.execPath} -e "process.exit(42)" {prompt}`, - }, - }); - assert.equal(noCostDefault.status, 0, `${noCostDefault.stdout || ""}${noCostDefault.stderr || ""}`); - const noCostSummary = JSON.parse(readFileSync(path.join(noCostDefaultReport, "summary.json"), "utf8")); - assert.equal(noCostSummary.estimated_llm_input_tokens, 0); - assert.equal(noCostSummary.estimated_llm_output_tokens, 0); -} finally { - rmSync(tmpRoot, { recursive: true, force: true }); -} - -console.log("Eval runner tests passed."); diff --git a/test/fixtures/fake-llm-eval.mjs b/test/fixtures/fake-llm-eval.mjs deleted file mode 100644 index bba3f6fc..00000000 --- a/test/fixtures/fake-llm-eval.mjs +++ /dev/null @@ -1,26 +0,0 @@ -const prompt = process.argv.slice(2).join(" "); - -console.log(` -Route: Use the narrow Productize skill for the requested artifact. Prompt received: ${prompt} - -Evidence: known facts, assumptions, missing inputs, and risky leaps are separated before the recommendation. - -Work product: -- Beachhead and validation plan for founder discovery. -- PRD, requirements, and acceptance criteria for delivery work. -- Board narrative with PMF evidence, roadmap tradeoff, risk, and decision ask. -- Agent handoff with architecture risk, retrieval failure mode, evals, and verification. -- Support themes, ticket volume, severity, and prioritized improvements. -- Decision memo comparing SSO, dashboards, and reliability with owner and DRI. -- Metrics validation plan with source of truth, warehouse reconciliation, lineage, freshness, completeness, and validation check. -- Valuation artifact with DCF, WACC, terminal value, enterprise value, equity value, market values, price per share, and sensitivity. -- VC deal artifact with cap table, dilution, pre-money, post-money, option pool, liquidation preference, convertible note, and SAFE. -- Dogfood QA report with Pages Tested, Flows Tested, Console Errors, Screenshots/Evidence, Severity Table, Blockers, sitemap, user flow, console error, and screenshot evidence. - -Warnings: -- Do not ship vague playbooks or filler. -- Do not confuse signups with sustainable growth, retention, CAC payback, or expansion. - -Next action: assign an owner, choose the validation metric, and hand off the artifact to the decision maker. -Recommendation: proceed with the smallest evidence-producing artifact first. -`); diff --git a/test/frontend_toolchain_test.go b/test/frontend_toolchain_test.go new file mode 100644 index 00000000..0cffbdc2 --- /dev/null +++ b/test/frontend_toolchain_test.go @@ -0,0 +1,86 @@ +package test + +import ( + "encoding/json" + "os" + "path/filepath" + "strings" + "testing" +) + +func TestRootWebToolchainIsRemoved(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + for _, rel := range []string{ + ".bun-version", + "bun.lock", + "turbo.json", + "vitest.config.ts", + "tsconfig.json", + ".oxlintrc.json", + ".oxfmtrc.json", + "web", + "packages", + "docs/design/daemon-mockup", + } { + if _, err := os.Stat(filepath.Join(root, rel)); err == nil { + t.Fatalf("expected removed web toolchain artifact %q to be absent", rel) + } else if !os.IsNotExist(err) { + t.Fatalf("stat %q: %v", rel, err) + } + } +} + +func TestRootPackageJSONDoesNotExposeFrontendTooling(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(filepath.Join(repoRoot(t), "package.json")) + if err != nil { + t.Fatalf("read package.json: %v", err) + } + + var pkg struct { + DevDependencies map[string]string `json:"devDependencies"` + Scripts map[string]string `json:"scripts"` + } + if err := json.Unmarshal(content, &pkg); err != nil { + t.Fatalf("unmarshal package.json: %v", err) + } + + for _, dep := range []string{"@vitejs/plugin-react", "vite", "vitest", "turbo", "oxlint"} { + if _, ok := pkg.DevDependencies[dep]; ok { + t.Fatalf("expected package.json not to depend on removed frontend tool %q", dep) + } + } + + for name, script := range pkg.Scripts { + for _, forbidden := range []string{"bun", "bunx", "turbo", "vite", "vitest", "oxlint"} { + if strings.Contains(name, forbidden) || strings.Contains(script, forbidden) { + t.Fatalf("expected script %q=%q not to reference %q", name, script, forbidden) + } + } + } +} + +func TestReleaseToolingDoesNotInstallBun(t *testing.T) { + t.Parallel() + + for _, rel := range []string{ + ".github/actions/setup-git-cliff/action.yml", + ".github/actions/setup-release/action.yml", + ".github/workflows/ci.yml", + ".github/workflows/release.yml", + } { + content, err := os.ReadFile(filepath.Join(repoRoot(t), rel)) + if err != nil { + t.Fatalf("read %s: %v", rel, err) + } + text := string(content) + for _, forbidden := range []string{"setup-bun", "bun install", "bunx", ".bun", "bun-version"} { + if strings.Contains(text, forbidden) { + t.Fatalf("expected %s not to contain removed Bun tooling %q", rel, forbidden) + } + } + } +} diff --git a/test/generator.test.mjs b/test/generator.test.mjs deleted file mode 100644 index cbce5ef6..00000000 --- a/test/generator.test.mjs +++ /dev/null @@ -1,63 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync, readFileSync } from "node:fs"; -import { spawnSync } from "node:child_process"; -import path from "node:path"; -import { hosts } from "../hosts/index.mjs"; -import { parseFrontmatter, repoRoot } from "../scripts/lib/productize.mjs"; - -for (const host of ["canonical", "codex"]) { - const dryRun = spawnSync(process.execPath, ["scripts/gen-skill-docs.mjs", "--host", host, "--dry-run", "--quiet"], { - cwd: repoRoot, - encoding: "utf8", - }); - const dryRunOutput = `${dryRun.stdout || ""}${dryRun.stderr || ""}`; - assert.equal(dryRun.status, 0, `${host} generated skill outputs are stale\n${dryRunOutput}`); - assert.doesNotMatch(dryRunOutput, /^STALE:/m); -} - -const rootSkill = readFile("SKILL.md"); -assert.match(rootSkill, /AUTO-GENERATED from SKILL\.md\.tmpl/); -assert.match(rootSkill, /## Productize Preamble/); -assert.match(rootSkill, /## Routing Map/); -assert.equal(parseFrontmatter(rootSkill).name, "productize"); - -const codexSkill = readFile(".agents/skills/productize-product-market-fit-cycle/SKILL.md"); -const codexFrontmatter = parseFrontmatter(codexSkill); -assert.equal(codexFrontmatter.name, "productize-product-market-fit-cycle"); -assert.ok(codexFrontmatter.description.length <= 1024, "Codex generated description must respect host limit"); -assert.match(codexSkill, /AUTO-GENERATED/); -assert.doesNotMatch(codexSkill, /Claude Code/); - -assertFile("agents/openai.yaml"); -assertFile("skills/product-market-fit-cycle/agents/openai.yaml"); -assertFile(".agents/skills/productize-product-market-fit-cycle/agents/openai.yaml"); - -for (const host of hosts) { - const manifest = readJson(path.join(host.hostSubdir, "productize-runtime.json")); - assert.equal(manifest.generated, true, `${host.name} runtime manifest must be generated`); - assert.equal(manifest.host, host.name); - assert.equal(manifest.adapter_source, host.adapterSource); - assert.ok( - manifest.sidecars.some((sidecar) => sidecar.source === "bin/productize-runtime.mjs"), - `${host.name} runtime manifest must include productize-runtime.mjs`, - ); - assert.ok( - manifest.sidecars.some((sidecar) => sidecar.source === "bin/productize-routing.mjs"), - `${host.name} runtime manifest must include shared routing module`, - ); - assertFile(path.join(host.outputRoot, "productize", "SKILL.md")); -} - -console.log("Generator tests passed."); - -function readFile(relativePath) { - return readFileSync(path.join(repoRoot, relativePath), "utf8"); -} - -function readJson(relativePath) { - return JSON.parse(readFile(relativePath)); -} - -function assertFile(relativePath) { - assert.ok(existsSync(path.join(repoRoot, relativePath)), `Missing file: ${relativePath}`); -} diff --git a/test/helpers_test.go b/test/helpers_test.go new file mode 100644 index 00000000..953906ef --- /dev/null +++ b/test/helpers_test.go @@ -0,0 +1,17 @@ +package test + +import ( + "path/filepath" + "runtime" + "testing" +) + +func repoRoot(t *testing.T) string { + t.Helper() + + _, file, _, ok := runtime.Caller(0) + if !ok { + t.Fatal("failed to resolve test file location") + } + return filepath.Clean(filepath.Join(filepath.Dir(file), "..")) +} diff --git a/test/metadata-quality.test.mjs b/test/metadata-quality.test.mjs deleted file mode 100644 index d9539d09..00000000 --- a/test/metadata-quality.test.mjs +++ /dev/null @@ -1,18 +0,0 @@ -import assert from "node:assert/strict"; -import { readFileSync } from "node:fs"; -import path from "node:path"; -import { metadataQualityIssues } from "../scripts/lib/metadata-quality.mjs"; -import { readAllSkills, skillsRoot } from "../scripts/lib/productize.mjs"; - -const failures = []; - -for (const skill of readAllSkills()) { - const manifestPath = path.join(skillsRoot, skill.skillName, "productize.json"); - const manifest = JSON.parse(readFileSync(manifestPath, "utf8")); - const issues = metadataQualityIssues({ skillName: skill.skillName, manifest }); - if (issues.length) failures.push(`${skill.skillName}: ${issues.join("; ")}`); -} - -assert.deepEqual(failures, [], `Metadata quality failures:\n${failures.join("\n")}`); - -console.log("Metadata quality tests passed."); diff --git a/test/plugin-distribution.test.mjs b/test/plugin-distribution.test.mjs deleted file mode 100644 index 3693f606..00000000 --- a/test/plugin-distribution.test.mjs +++ /dev/null @@ -1,43 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync } from "node:fs"; -import path from "node:path"; -import { findDistributionInternals } from "../scripts/lib/distribution.mjs"; -import { pluginsRoot, repoRoot } from "../scripts/lib/productize.mjs"; - -const pluginInternals = findDistributionInternals(pluginsRoot); -assert.deepEqual( - pluginInternals, - [], - `Plugin bundles must not include canonical internals:\n${formatInternals(pluginInternals)}`, -); - -for (const hostRoot of [".agents/skills", ".claude/skills", ".cursor/skills", ".opencode/skills", ".factory/skills"]) { - const absolute = path.join(repoRoot, hostRoot); - if (!existsSync(absolute)) continue; - const internals = findDistributionInternals(absolute); - assert.deepEqual( - internals, - [], - `${hostRoot} must not include canonical internals:\n${formatInternals(internals)}`, - ); -} - -assertFile("plugins/productize-growth/skills/productize-plg-growth-playbook/SKILL.md"); -assertNoFile("plugins/productize-growth/skills/plg-growth-playbook/SKILL.md"); -assertFile("plugins/productize-finance/skills/productize-finance-modeling-kernel/finance-modeling-kernel/dcf.py"); -assertNoFile("plugins/productize-finance/skills/productize-finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py"); -assertNoFile(".agents/skills/productize-finance-modeling-kernel/finance-modeling-kernel/tests/test_acceptance.py"); - -console.log("Plugin distribution tests passed."); - -function assertFile(relativePath) { - assert.ok(existsSync(path.join(repoRoot, relativePath)), `Missing file: ${relativePath}`); -} - -function assertNoFile(relativePath) { - assert.ok(!existsSync(path.join(repoRoot, relativePath)), `Forbidden file exists: ${relativePath}`); -} - -function formatInternals(items) { - return items.map((item) => `- ${item.path} (${item.reason})`).join("\n"); -} diff --git a/test/public_api_test.go b/test/public_api_test.go new file mode 100644 index 00000000..3906b5e3 --- /dev/null +++ b/test/public_api_test.go @@ -0,0 +1,214 @@ +package test + +import ( + "context" + "os" + "path/filepath" + "strings" + "testing" + + "github.com/itseffi/productize" + "github.com/itseffi/productize/internal/core/model" + "github.com/itseffi/productize/pkg/productize/runs/layout" +) + +func TestPrepareAndRunExposePublicAPI(t *testing.T) { + workspaceRoot := t.TempDir() + t.Setenv("HOME", filepath.Join(t.TempDir(), "home")) + tasksDir := filepath.Join(workspaceRoot, ".productize", "tasks", "demo") + if err := os.MkdirAll(tasksDir, 0o755); err != nil { + t.Fatalf("mkdir tasks dir: %v", err) + } + + taskFile := filepath.Join(tasksDir, "task_1.md") + taskContent := `--- +status: pending +title: Demo +type: backend +complexity: low +--- + +# Task 1: Demo +` + if err := os.WriteFile(taskFile, []byte(taskContent), 0o600); err != nil { + t.Fatalf("write task file: %v", err) + } + + cfg := productize.Config{ + Name: "demo", + TasksDir: tasksDir, + WorkspaceRoot: workspaceRoot, + Mode: productize.ModePRDTasks, + DryRun: true, + } + + prep, err := productize.Prepare(context.Background(), cfg) + if err != nil { + t.Fatalf("prepare: %v", err) + } + if prep == nil { + t.Fatal("expected preparation result") + } + if len(prep.Jobs) != 1 { + t.Fatalf("expected 1 job, got %d", len(prep.Jobs)) + } + if prep.Jobs[0].PromptPath == "" { + t.Fatal("expected prompt path to be populated") + } + + if err := productize.Run(context.Background(), cfg); err != nil { + t.Fatalf("run: %v", err) + } +} + +func TestNewCommandUsesProductizeRootCommand(t *testing.T) { + t.Parallel() + + cmd := productize.NewCommand() + if cmd == nil { + t.Fatal("expected command") + } + if cmd.Use != "productize" { + t.Fatalf("expected use productize, got %q", cmd.Use) + } +} + +func TestMigrateExposePublicAPI(t *testing.T) { + tmpDir := t.TempDir() + t.Chdir(tmpDir) + + workflowDir := filepath.Join(tmpDir, ".productize", "tasks", "demo") + if err := os.MkdirAll(workflowDir, 0o755); err != nil { + t.Fatalf("mkdir workflow dir: %v", err) + } + if err := os.WriteFile(filepath.Join(workflowDir, "task_1.md"), []byte(strings.Join([]string{ + "## status: pending", + "backendfeaturesmalllow", + "# Task 1: Demo", + "", + }, "\n")), 0o600); err != nil { + t.Fatalf("write legacy task: %v", err) + } + + result, err := productize.Migrate(context.Background(), productize.MigrationConfig{DryRun: true}) + if err != nil { + t.Fatalf("migrate: %v", err) + } + if result == nil { + t.Fatal("expected migration result") + } + if result.FilesMigrated != 1 { + t.Fatalf("expected 1 planned migration, got %d", result.FilesMigrated) + } +} + +func TestSyncExposePublicAPI(t *testing.T) { + tmpDir := t.TempDir() + t.Setenv("HOME", filepath.Join(tmpDir, "home")) + workflowDir := filepath.Join(tmpDir, ".productize", "tasks", "demo") + if err := os.MkdirAll(workflowDir, 0o755); err != nil { + t.Fatalf("mkdir workflow dir: %v", err) + } + if err := os.WriteFile(filepath.Join(workflowDir, "task_1.md"), []byte(strings.Join([]string{ + "---", + "status: pending", + "title: Demo", + "type: backend", + "complexity: low", + "---", + "", + "# Task 1: Demo", + "", + }, "\n")), 0o600); err != nil { + t.Fatalf("write task file: %v", err) + } + + result, err := productize.Sync(context.Background(), productize.SyncConfig{TasksDir: workflowDir}) + if err != nil { + t.Fatalf("sync: %v", err) + } + if result == nil { + t.Fatal("expected sync result") + } + if result.WorkflowsScanned != 1 || + result.TaskItemsUpserted != 1 || + result.SnapshotsUpserted != 1 || + result.CheckpointsUpdated != 1 { + t.Fatalf("unexpected sync result: %#v", result) + } +} + +func TestArchiveExposePublicAPI(t *testing.T) { + tmpDir := t.TempDir() + t.Setenv("HOME", filepath.Join(tmpDir, "home")) + workflowDir := filepath.Join(tmpDir, ".productize", "tasks", "demo") + if err := os.MkdirAll(workflowDir, 0o755); err != nil { + t.Fatalf("mkdir workflow dir: %v", err) + } + if err := os.WriteFile(filepath.Join(workflowDir, "task_001.md"), []byte(strings.Join([]string{ + "---", + "status: completed", + "title: Demo", + "type: backend", + "complexity: low", + "---", + "", + "# Task 1: Demo", + "", + }, "\n")), 0o600); err != nil { + t.Fatalf("write task file: %v", err) + } + + if _, err := productize.Sync(context.Background(), productize.SyncConfig{TasksDir: workflowDir}); err != nil { + t.Fatalf("sync before archive: %v", err) + } + + result, err := productize.Archive(context.Background(), productize.ArchiveConfig{TasksDir: workflowDir}) + if err != nil { + t.Fatalf("archive: %v", err) + } + if result == nil { + t.Fatal("expected archive result") + } + if result.Archived != 1 || result.Skipped != 0 { + t.Fatalf("unexpected archive result: %#v", result) + } + if len(result.ArchivedPaths) != 1 { + t.Fatalf("expected one archived path, got %#v", result.ArchivedPaths) + } + if _, err := os.Stat(result.ArchivedPaths[0]); err != nil { + t.Fatalf("expected archived path to exist: %v", err) + } +} + +// TestRunsLayoutAgreesAcrossWriterAndPublicLayout proves that the canonical +// writer (model.NewRunArtifacts) and the public compatibility layout package +// still agree on artifact names even though run reading itself is daemon-backed. +func TestRunsLayoutAgreesAcrossWriterAndPublicLayout(t *testing.T) { + t.Parallel() + + workspaceRoot := t.TempDir() + const runID = "agree-test" + + artifacts := model.NewRunArtifacts(workspaceRoot, runID) + + cases := []struct { + name string + writer string + reader string + }{ + {"run meta", artifacts.RunMetaPath, layout.RunMetaPath(artifacts.RunDir)}, + {"events log", artifacts.EventsPath, layout.EventsLogPath(artifacts.RunDir)}, + {"result", artifacts.ResultPath, layout.ResultPath(artifacts.RunDir)}, + {"jobs dir", artifacts.JobsDir, layout.JobsDir(artifacts.RunDir)}, + {"turns dir", artifacts.TurnsDir, layout.TurnsDir(artifacts.RunDir)}, + } + for _, tc := range cases { + t.Run(tc.name, func(t *testing.T) { + t.Parallel() + if tc.writer != tc.reader { + t.Errorf("writer=%q reader=%q (writer/reader disagree on layout)", tc.writer, tc.reader) + } + }) + } +} diff --git a/test/registry.test.mjs b/test/registry.test.mjs deleted file mode 100644 index 4e0e8060..00000000 --- a/test/registry.test.mjs +++ /dev/null @@ -1,80 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync, readFileSync } from "node:fs"; -import path from "node:path"; -import { - categoryOrder, - lifecycleOrder, - pluginsRoot, - readAllSkills, - registryRoot, - repoRoot, -} from "../scripts/lib/productize.mjs"; - -const registrySkills = readRegistry("skills.json"); -const canonicalSkills = readAllSkills(); -const registryNames = new Set(registrySkills.map((skill) => skill.name)); -const canonicalNames = new Set(canonicalSkills.map((skill) => skill.skillName)); - -assert.equal(registrySkills.length, canonicalSkills.length, "registry skills count must match canonical skills"); -assert.deepEqual([...registryNames].sort(), [...canonicalNames].sort(), "registry skill names must match canonical skills"); - -for (const skill of registrySkills) { - assert.ok(skill.name, "skill name is required"); - assert.ok(skill.title, `${skill.name} title is required`); - assert.ok(skill.category, `${skill.name} category is required`); - assert.ok(skill.lifecycle, `${skill.name} lifecycle is required`); - assert.ok(Array.isArray(skill.routing_signals) && skill.routing_signals.length > 0, `${skill.name} routing_signals are required`); - assert.ok(Array.isArray(skill.examples) && skill.examples.length > 0, `${skill.name} examples are required`); - assertFile(skill.source_path); - assertFile(skill.template_path); - assert.ok(skill.plugin?.startsWith("productize-"), `${skill.name} must name a Productize plugin`); -} - -const lifecycleRegistry = readRegistry("lifecycle.json"); -const lifecycleCounts = countBy(registrySkills, "lifecycle"); -assert.deepEqual(lifecycleRegistry.map((entry) => entry.lifecycle), lifecycleOrder); -for (const entry of lifecycleRegistry) { - assert.equal(entry.skill_count, lifecycleCounts.get(entry.lifecycle) || 0, `${entry.lifecycle} count mismatch`); - assert.equal(entry.skills.length, entry.skill_count, `${entry.lifecycle} skills list count mismatch`); -} -assert.equal([...lifecycleCounts.values()].reduce((sum, count) => sum + count, 0), registrySkills.length); - -const categoryRegistry = readRegistry("categories.json"); -const categoryCounts = countBy(registrySkills, "category"); -assert.deepEqual(categoryRegistry.map((entry) => entry.category), categoryOrder); -for (const entry of categoryRegistry) { - assert.equal(entry.skill_count, categoryCounts.get(entry.category) || 0, `${entry.category} count mismatch`); - assert.equal(entry.skills.length, entry.skill_count, `${entry.category} skills list count mismatch`); -} - -const plugins = readRegistry("plugins.json"); -const allPlugin = plugins.find((plugin) => plugin.name === "productize-all"); -assert.ok(allPlugin, "productize-all plugin registry entry is required"); -assert.equal(allPlugin.skill_count, registrySkills.length, "productize-all skill count must match registry"); -for (const category of categoryOrder) { - const plugin = plugins.find((entry) => entry.name === `productize-${slug(category)}`); - assert.ok(plugin, `Missing plugin registry entry for ${category}`); - assert.equal(plugin.skill_count, categoryCounts.get(category) || 0, `${category} plugin skill count mismatch`); - assertFile(path.join(pluginsRoot, plugin.name, ".codex-plugin", "plugin.json")); -} - -console.log("Registry tests passed."); - -function readRegistry(file) { - return JSON.parse(readFileSync(path.join(registryRoot, file), "utf8")); -} - -function assertFile(relativePath) { - const absolute = path.isAbsolute(relativePath) ? relativePath : path.join(repoRoot, relativePath); - assert.ok(existsSync(absolute), `Missing file: ${relativePath}`); -} - -function countBy(items, field) { - const counts = new Map(); - for (const item of items) counts.set(item[field], (counts.get(item[field]) || 0) + 1); - return counts; -} - -function slug(value) { - return String(value).toLowerCase().replace(/[^a-z0-9]+/g, "-").replace(/^-|-$/g, ""); -} diff --git a/test/release.test.mjs b/test/release.test.mjs deleted file mode 100644 index 6462a5f0..00000000 --- a/test/release.test.mjs +++ /dev/null @@ -1,66 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync, readFileSync } from "node:fs"; -import { spawnSync } from "node:child_process"; -import path from "node:path"; -import { repoRoot } from "../scripts/lib/productize.mjs"; - -const packagePath = path.join(repoRoot, "package.json"); -const versionPath = path.join(repoRoot, "VERSION"); -const changelogPath = path.join(repoRoot, "CHANGELOG.md"); - -const beforePackage = readFileSync(packagePath, "utf8"); -const beforeVersion = readFileSync(versionPath, "utf8"); -const beforeChangelog = readFileSync(changelogPath, "utf8"); -const dryRunVersion = `0.0.0-dryrun.${Date.now()}`; -const dryRunManifest = path.join(repoRoot, "dist", `productize-release-${dryRunVersion}.json`); - -const releaseCheck = run([process.execPath, "scripts/release-check.mjs"]); -assert.match(releaseCheck.stdout, /Release check passed/); - -assert.equal(existsSync(dryRunManifest), false, "dry-run test manifest should not already exist"); -const dryRun = run([ - process.execPath, - "scripts/release.mjs", - "--dry-run", - "--version", - dryRunVersion, - "--skip-build", - "--skip-tests", - "--skip-evals", - "--skip-smoke", -]); -assert.match(dryRun.stdout, /DRY RUN npm run release:check/); -assert.match(dryRun.stdout, /DRY RUN npm run upgrade:check/); -assert.doesNotMatch(dryRun.stdout, /Release check passed/); -assertUnchanged(); -assert.equal(existsSync(dryRunManifest), false, "release dry-run must not write a release manifest"); - -const invalid = spawnSync( - process.execPath, - ["scripts/release.mjs", "--dry-run", "--version", "not-a-version", "--skip-build", "--skip-tests", "--skip-evals", "--skip-smoke"], - { - cwd: repoRoot, - encoding: "utf8", - }, -); -assert.notEqual(invalid.status, 0, "invalid release version must fail"); -assert.match(`${invalid.stdout || ""}${invalid.stderr || ""}`, /semver/); -assertUnchanged(); - -console.log("Release tests passed."); - -function run(command) { - const result = spawnSync(command[0], command.slice(1), { - cwd: repoRoot, - encoding: "utf8", - }); - const output = `${result.stdout || ""}${result.stderr || ""}`; - assert.equal(result.status, 0, `${command.join(" ")} failed\n${output}`); - return result; -} - -function assertUnchanged() { - assert.equal(readFileSync(packagePath, "utf8"), beforePackage, "release tests must not mutate package.json"); - assert.equal(readFileSync(versionPath, "utf8"), beforeVersion, "release tests must not mutate VERSION"); - assert.equal(readFileSync(changelogPath, "utf8"), beforeChangelog, "release tests must not mutate CHANGELOG.md"); -} diff --git a/test/release_config_test.go b/test/release_config_test.go new file mode 100644 index 00000000..f02beb94 --- /dev/null +++ b/test/release_config_test.go @@ -0,0 +1,518 @@ +package test + +import ( + "encoding/json" + "os" + "path/filepath" + "slices" + "strings" + "testing" + + "gopkg.in/yaml.v3" +) + +type goReleaserConfig struct { + Before goReleaserBefore `yaml:"before"` + Archives []goReleaserArchive `yaml:"archives"` + HomebrewCasks []goReleaserHomebrewFormula `yaml:"homebrew_casks"` +} + +type goReleaserBefore struct { + Hooks []string `yaml:"hooks"` +} + +type goReleaserArchive struct { + ID string `yaml:"id"` + WrapInDirectory bool `yaml:"wrap_in_directory"` +} + +type goReleaserHomebrewFormula struct { + Name string `yaml:"name"` + IDs []string `yaml:"ids"` + Binaries []string `yaml:"binaries"` + Directory string `yaml:"directory"` + Repository goReleaserRepository `yaml:"repository"` +} + +type goReleaserRepository struct { + Owner string `yaml:"owner"` + Name string `yaml:"name"` +} + +func TestReleaseWorkflowsUseScopedReleaseNotesGenerator(t *testing.T) { + t.Parallel() + + const fixedModule = "github.com/productize/releasepr@v0.0.21" + brokenModules := []string{ + "github.com/productize/releasepr@v0.0.17", + "github.com/productize/releasepr@v0.0.18", + "github.com/productize/releasepr@v0.0.19", + "github.com/productize/releasepr@v0.0.20", + } + workflowPaths := []string{ + filepath.Join(repoRoot(t), ".github", "workflows", "auto-docs.yml"), + filepath.Join(repoRoot(t), ".github", "workflows", "release.yml"), + } + + for _, workflowPath := range workflowPaths { + workflowPath := workflowPath + t.Run(filepath.Base(workflowPath), func(t *testing.T) { + t.Parallel() + content, err := os.ReadFile(workflowPath) + if err != nil { + t.Fatalf("read release workflow: %v", err) + } + text := string(content) + if !strings.Contains(text, "PR_RELEASE_MODULE: "+fixedModule) { + t.Fatalf("expected workflow to use fixed releasepr module %q", fixedModule) + } + for _, brokenModule := range brokenModules { + if strings.Contains(text, brokenModule) { + t.Fatalf("expected workflow to avoid broken releasepr module %q", brokenModule) + } + } + }) + } +} + +func TestReleasePublicationUsesGeneratedChangelog(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + releaseWorkflow := readRepoFile(t, root, ".github", "workflows", "release.yml") + goReleaserConfig := readRepoFile(t, root, ".goreleaser.yml") + gitignore := readRepoFile(t, root, ".gitignore") + + if strings.Contains(releaseWorkflow, "--release-notes=RELEASE_BODY.md") { + t.Fatal("expected GoReleaser to use generated changelog notes instead of stale release body") + } + if strings.Contains(releaseWorkflow, "--release-notes=RELEASE_NOTES.md") { + t.Fatal("expected GoReleaser to avoid publishing historical release notes") + } + if !strings.Contains(releaseWorkflow, "--release-header-tmpl=.goreleaser.release-header.md.tmpl") { + t.Fatal("expected release workflow to pass the release header template to GoReleaser") + } + if !strings.Contains(releaseWorkflow, "--release-footer-tmpl=.goreleaser.release-footer.md.tmpl") { + t.Fatal("expected release workflow to pass the release footer template to GoReleaser") + } + if !strings.Contains(goReleaserConfig, "changelog:") || !strings.Contains(goReleaserConfig, "use: git") { + t.Fatal("expected GoReleaser to generate release notes from git changelog configuration") + } + if !strings.Contains(gitignore, "RELEASE_BODY.md") { + t.Fatal("expected stale release body files to be ignored") + } +} + +func TestGoReleaserConfigSupportsFirstRelease(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(filepath.Join(repoRoot(t), ".goreleaser.yml")) + if err != nil { + t.Fatalf("read goreleaser config: %v", err) + } + + configText := string(content) + + if strings.Contains(configText, "use: github") { + t.Fatal( + "expected goreleaser changelog generation to avoid the GitHub compare API so the first release works without a previous remote tag", + ) + } + + if !strings.Contains(configText, "use: git") { + t.Fatal("expected goreleaser changelog generation to use git history for first-release compatibility") + } + + footerContent, err := os.ReadFile(filepath.Join(repoRoot(t), ".goreleaser.release-footer.md.tmpl")) + if err != nil { + t.Fatalf("read goreleaser release footer template: %v", err) + } + + footerText := string(footerContent) + + if !strings.Contains(footerText, "{{- if .PreviousTag }}") { + t.Fatal("expected release notes to guard previous-tag links for the first release") + } + + if !strings.Contains(footerText, "compare/{{ .PreviousTag }}...{{ .Tag }}") { + t.Fatal("expected release notes to keep the compare link when a previous tag exists") + } + + if !strings.Contains(footerText, "tree/{{ .Tag }}") { + t.Fatal("expected release notes to include a first-release fallback link when no previous tag exists") + } + + workflowContent, err := os.ReadFile(filepath.Join(repoRoot(t), ".github", "workflows", "release.yml")) + if err != nil { + t.Fatalf("read release workflow: %v", err) + } + + if !strings.Contains(string(workflowContent), "--release-footer-tmpl=.goreleaser.release-footer.md.tmpl") { + t.Fatal("expected the release workflow to pass the first-release footer template to goreleaser") + } +} + +func TestReleaseUsesFreeGoReleaserAndCustomNPMWrapper(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + goreleaserContent := readRepoFile(t, root, ".goreleaser.yml") + var rawGoReleaser map[string]any + if err := yaml.Unmarshal([]byte(goreleaserContent), &rawGoReleaser); err != nil { + t.Fatalf("unmarshal goreleaser config: %v", err) + } + + if strings.Contains(goreleaserContent, "schema-pro") { + t.Fatal("expected GoReleaser config to use the free schema") + } + if _, ok := rawGoReleaser["pro"]; ok { + t.Fatal("expected GoReleaser config to avoid the pro-only top-level pro flag") + } + if _, ok := rawGoReleaser["npms"]; ok { + t.Fatal("expected npm publishing to use the custom wrapper instead of the pro-only npms block") + } + if metadata, ok := rawGoReleaser["metadata"].(map[string]any); ok { + for _, proOnlyField := range []string{"license", "homepage", "description"} { + if _, ok := metadata[proOnlyField]; ok { + t.Fatalf("expected metadata to avoid pro-only field %q", proOnlyField) + } + } + } + + workflow := readRepoFile(t, root, ".github", "workflows", "release.yml") + for _, forbidden := range []string{"GORELEASER_KEY", "goreleaser-pro"} { + if strings.Contains(workflow, forbidden) { + t.Fatalf("expected release workflow to avoid %q", forbidden) + } + } + for _, required := range []string{ + "distribution: goreleaser", + "id: release-version", + "node npm/cli/prepare-package.mjs", + "--out dist/npm/@productize/cli", + "npm publish dist/npm/@productize/cli --access public", + } { + if !strings.Contains(workflow, required) { + t.Fatalf("expected release workflow to include %q", required) + } + } + + setupRelease := readRepoFile(t, root, ".github", "actions", "setup-release", "action.yml") + if !strings.Contains(setupRelease, `default: "goreleaser"`) { + t.Fatal("expected setup-release to default to free GoReleaser") + } + + npmManifest := readRepoFile(t, root, "npm", "cli", "package.json") + var npmPackage struct { + Name string `json:"name"` + Private bool `json:"private"` + Bin map[string]string `json:"bin"` + License string `json:"license"` + } + if err := json.Unmarshal([]byte(npmManifest), &npmPackage); err != nil { + t.Fatalf("decode npm cli package manifest: %v", err) + } + if npmPackage.Name != "@productize/cli" { + t.Fatalf("expected npm wrapper package name @productize/cli, got %q", npmPackage.Name) + } + if !npmPackage.Private { + t.Fatal("expected source npm wrapper package to be private so only generated packages are published") + } + if npmPackage.Bin["productize"] != "run-productize.js" { + t.Fatalf("expected npm wrapper binary to point at run-productize.js, got %q", npmPackage.Bin["productize"]) + } + if npmPackage.License != "MIT" { + t.Fatalf("expected npm wrapper package license MIT, got %q", npmPackage.License) + } + + prepareScript := readRepoFile(t, root, "npm", "cli", "prepare-package.mjs") + for _, required := range []string{ + "delete manifest.private", + "darwin", + "linux", + "windows", + "copyTargetBinary", + } { + if !strings.Contains(prepareScript, required) { + t.Fatalf("expected npm package preparation script to include %q", required) + } + } +} + +func readRepoFile(t *testing.T, root string, path ...string) string { + t.Helper() + content, err := os.ReadFile(filepath.Join(append([]string{root}, path...)...)) + if err != nil { + t.Fatalf("read repo file %s: %v", filepath.Join(path...), err) + } + return string(content) +} + +func TestGoReleaserConfigUsesReadableChangelogTitlesAndFiltersReleaseCommits(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(filepath.Join(repoRoot(t), ".goreleaser.yml")) + if err != nil { + t.Fatalf("read goreleaser config: %v", err) + } + + text := string(content) + + expectedTitles := []string{ + `title: "๐ŸŽ‰ Features"`, + `title: "๐Ÿ› Bug Fixes"`, + `title: "โšก Performance Improvements"`, + `title: "๐Ÿ”’ Security"`, + `title: "๐Ÿ“š Documentation"`, + `title: "โ™ป๏ธ Refactoring"`, + `title: "๐Ÿ“ฆ Dependencies"`, + `title: "๐Ÿงช Testing"`, + `title: "Other Changes"`, + } + + for _, title := range expectedTitles { + title := title + t.Run("Should include readable title "+title, func(t *testing.T) { + t.Parallel() + if !strings.Contains(text, title) { + t.Fatalf("expected goreleaser changelog config to include readable group title %q", title) + } + }) + } + + unexpectedTitles := []string{ + `title: "\U0001F389"`, + `title: "\U0001F41B"`, + `title: "โšก"`, + `title: "\U0001F510"`, + `title: "\U0001F4DA"`, + `title: "\U0001F527"`, + `title: "\U0001F4E6"`, + `title: "\U0001F9EA"`, + `title: "\U0001F504"`, + } + + for _, title := range unexpectedTitles { + title := title + t.Run("Should avoid emoji-only title "+title, func(t *testing.T) { + t.Parallel() + if strings.Contains(text, title) { + t.Fatalf("expected goreleaser changelog config to avoid emoji-only group title %q", title) + } + }) + } + + expectedFilters := []string{ + `- "^ci\\(release\\): "`, + `- "^chore\\(release\\): "`, + } + + for _, filter := range expectedFilters { + filter := filter + t.Run("Should exclude release automation filter "+filter, func(t *testing.T) { + t.Parallel() + if !strings.Contains(text, filter) { + t.Fatalf( + "expected goreleaser changelog config to exclude release automation commits with filter %q", + filter, + ) + } + }) + } +} + +func TestSetupReleaseActionUsesSupportedCosignVersionCommand(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(filepath.Join(repoRoot(t), ".github", "actions", "setup-release", "action.yml")) + if err != nil { + t.Fatalf("read setup-release action: %v", err) + } + + text := string(content) + + if strings.Contains(text, "cosign version --short") { + t.Fatal("expected setup-release to avoid the unsupported `cosign version --short` command") + } + + if !strings.Contains(text, "echo \"Cosign version:\"") { + t.Fatal("expected setup-release to print a cosign version header before running the standalone version command") + } + + if !strings.Contains(text, "\n cosign version\n") { + t.Fatal( + "expected setup-release to run `cosign version` as a standalone command so failures are not hidden inside command substitution", + ) + } +} + +func TestGoReleaserBuildsGoBinaryWithoutFrontendBundle(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(filepath.Join(repoRoot(t), ".goreleaser.yml")) + if err != nil { + t.Fatalf("read goreleaser config: %v", err) + } + + var cfg goReleaserConfig + if err := yaml.Unmarshal(content, &cfg); err != nil { + t.Fatalf("unmarshal goreleaser config: %v", err) + } + + // GoReleaser's own `builds:` block cross-compiles the binary (and surfaces any + // compile error), so a `before` build hook is redundant and intentionally absent. + // The invariant that matters: no frontend bundle build sneaks back in. + for _, hook := range cfg.Before.Hooks { + if hook == "make frontend-build" { + t.Fatal("expected GoReleaser to avoid frontend bundle builds") + } + } + + workflowContent, err := os.ReadFile(filepath.Join(repoRoot(t), ".github", "workflows", "release.yml")) + if err != nil { + t.Fatalf("read release workflow: %v", err) + } + workflow := string(workflowContent) + + dryRunBlock := workflowJobBlock(t, workflow, "dry-run", "release") + if strings.Contains(dryRunBlock, "setup-bun") { + t.Fatal("expected release dry-run to avoid Bun setup") + } + + releaseBlock := workflowJobBlock(t, workflow, "release", "") + if strings.Contains(releaseBlock, "setup-bun") { + t.Fatal("expected production release to avoid Bun setup") + } +} + +func TestGoReleaserConfigPublishesHomebrewCaskFromKnownArchives(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(filepath.Join(repoRoot(t), ".goreleaser.yml")) + if err != nil { + t.Fatalf("read goreleaser config: %v", err) + } + + var cfg goReleaserConfig + if err := yaml.Unmarshal(content, &cfg); err != nil { + t.Fatalf("unmarshal goreleaser config: %v", err) + } + + if strings.Contains(string(content), "\nbrews:") { + t.Fatal("expected goreleaser config to avoid deprecated Homebrew formulas") + } + if len(cfg.HomebrewCasks) == 0 { + t.Fatal("expected goreleaser config to define at least one Homebrew cask") + } + + archiveByID := make(map[string]goReleaserArchive, len(cfg.Archives)) + archiveIDs := make([]string, 0, len(cfg.Archives)) + for _, archive := range cfg.Archives { + if strings.TrimSpace(archive.ID) == "" { + continue + } + archiveByID[archive.ID] = archive + archiveIDs = append(archiveIDs, archive.ID) + } + + if len(archiveByID) == 0 { + t.Fatal("expected goreleaser config to define archive IDs") + } + + for _, cask := range cfg.HomebrewCasks { + cask := cask + t.Run(cask.Name, func(t *testing.T) { + t.Parallel() + + if cask.Directory != "Casks" { + t.Fatalf( + "expected Homebrew cask %q to be written under Casks, got %q", + cask.Name, + cask.Directory, + ) + } + if cask.Repository.Owner != "itseffi" || cask.Repository.Name != "homebrew-productize" { + t.Fatalf( + "expected Homebrew cask %q to publish to itseffi/homebrew-productize, got %s/%s", + cask.Name, + cask.Repository.Owner, + cask.Repository.Name, + ) + } + if !slices.Contains(cask.Binaries, "productize") { + t.Fatalf("expected Homebrew cask %q to install productize", cask.Name) + } + + targetIDs := cask.IDs + if len(targetIDs) == 0 { + targetIDs = archiveIDs + } + + for _, id := range targetIDs { + archive, ok := archiveByID[id] + if !ok { + t.Fatalf("expected Homebrew cask %q to reference a known archive id %q", cask.Name, id) + } + if archive.WrapInDirectory { + t.Fatalf( + "expected Homebrew cask archive %q to keep the binary at the archive root so brew can install it directly", + id, + ) + } + } + }) + } +} + +func TestHomebrewInstallDocsUseCaskTap(t *testing.T) { + t.Parallel() + + const installCommand = "brew install --cask itseffi/productize/productize" + forbiddenCommands := []string{ + "brew install itseffi/productize/productize", + "productize/tap/productize", + "homebrew-tap", + "brew install --cask productize", + } + paths := []string{ + "README.md", + ".goreleaser.release-header.md.tmpl", + } + + for _, path := range paths { + path := path + t.Run(path, func(t *testing.T) { + t.Parallel() + + content := readRepoFile(t, repoRoot(t), path) + if !strings.Contains(content, installCommand) { + t.Fatalf("expected %s to document %q", path, installCommand) + } + for _, forbiddenCommand := range forbiddenCommands { + if strings.Contains(content, forbiddenCommand) { + t.Fatalf("expected %s to avoid retired Homebrew command %q", path, forbiddenCommand) + } + } + }) + } +} + +func workflowJobBlock(t *testing.T, workflow string, jobName string, nextJobName string) string { + t.Helper() + + startNeedle := "\n " + jobName + ":\n" + start := strings.Index(workflow, startNeedle) + if start == -1 { + t.Fatalf("expected workflow to contain job %q", jobName) + } + start += len("\n") + if nextJobName == "" { + return workflow[start:] + } + endNeedle := "\n " + nextJobName + ":\n" + end := strings.Index(workflow[start:], endNeedle) + if end == -1 { + t.Fatalf("expected workflow job %q to be followed by %q", jobName, nextJobName) + } + return workflow[start : start+end] +} diff --git a/test/repo-hygiene.test.mjs b/test/repo-hygiene.test.mjs deleted file mode 100644 index c1305501..00000000 --- a/test/repo-hygiene.test.mjs +++ /dev/null @@ -1,29 +0,0 @@ -import assert from "node:assert/strict"; -import { spawnSync } from "node:child_process"; -import { repoRoot } from "../scripts/lib/productize.mjs"; - -const local = run(["scripts/check-repo-hygiene.mjs", "--allow-copied-tree"]); -assert.match(`${local.stdout}${local.stderr}`, /Repo hygiene passed/); - -const strict = spawnSync(process.execPath, ["scripts/check-repo-hygiene.mjs"], { - cwd: repoRoot, - encoding: "utf8", -}); - -if (strict.status === 0) { - assert.match(strict.stdout, /Repo hygiene passed/); -} else { - assert.match(`${strict.stdout || ""}${strict.stderr || ""}`, /not a git checkout|Git top-level mismatch/); -} - -console.log("Repo hygiene tests passed."); - -function run(command) { - const result = spawnSync(process.execPath, command, { - cwd: repoRoot, - encoding: "utf8", - }); - const output = `${result.stdout || ""}${result.stderr || ""}`; - assert.equal(result.status, 0, `${command.join(" ")} failed\n${output}`); - return result; -} diff --git a/test/route-regression.test.mjs b/test/route-regression.test.mjs deleted file mode 100644 index 0ee1e8b8..00000000 --- a/test/route-regression.test.mjs +++ /dev/null @@ -1,120 +0,0 @@ -import assert from "node:assert/strict"; -import { readdirSync, readFileSync } from "node:fs"; -import path from "node:path"; -import { route as runtimeRoute } from "../bin/productize-runtime.mjs"; -import { routeProductizeSkills } from "../bin/productize-routing.mjs"; -import { readAllSkills, repoRoot } from "../scripts/lib/productize.mjs"; - -const canonicalSkills = readAllSkills(); -const registrySkills = JSON.parse(readFileSync(path.join(repoRoot, "registry", "skills.json"), "utf8")); - -const cases = [ - { - name: "0-1 product build loop", - query: - "Use productize-0-1 to build the first version of a new AI workflow product: scope capability, curate data, design evals, run evals, analyze failures, and apply fixes.", - top: "0-1", - lifecycle: "Think", - }, - { - name: "0-1 founder beachhead", - query: "We are pre-seed and need to choose the first beachhead segment for a workflow automation idea", - top: "beachhead-segment", - lifecycle: "Strategize", - }, - { - name: "PLG bottleneck", - query: "Our CAC is rising and activation is flat; diagnose the PLG growth bottleneck and PQL handoff", - top: "plg-growth-playbook", - lifecycle: "Growth", - }, - { - name: "messy transcript to PRD", - query: "Write a PRD from this messy sales call transcript and design notes", - top: "prds-from-industry-and-feature-specifications", - lifecycle: "Plan", - }, - { - name: "CPO board update", - query: "We need a board update narrative for an executive product review", - top: "stakeholder-update", - lifecycle: "Align", - }, - { - name: "PMF check", - query: "Is this PMF? We have repeat usage but weak referrals", - top: "product-market-fit-cycle", - lifecycle: "Growth", - disallowedTop: ["structured-product-strategy-from-product-context", "task-specific-product-strategy-design"], - }, - { - name: "AI builder handoff", - query: "Create an agent-ready implementation spec and verification plan for an AI builder", - top: "spec-writing", - lifecycle: "Build With AI", - }, - { - name: "running implementation notes", - query: - "Implement this spec and maintain implementation-notes.html with decisions not in the spec, deviations, tradeoffs, open questions, and verification.", - top: "implementation-notes", - lifecycle: "Build With AI", - }, - { - name: "valuation deal pricing", - query: "What should we pay for this company? Need enterprise value, equity value, and price per share", - top: "valuation-and-deal-pricing", - category: "Finance", - }, - { - name: "group decision quality", - query: "The team is stuck in groupthink and needs a better decision process before the roadmap call", - top: "group-decision-making-quality-review", - category: "Decision Making", - }, -]; - -for (const testCase of cases) { - const canonical = routeProductizeSkills(testCase.query, canonicalSkills, 5); - const registry = routeProductizeSkills(testCase.query, registrySkills, 5); - const runtime = runtimeRoute(testCase.query, 5); - assert.ok(canonical.length, `${testCase.name}: canonical route returned no results`); - assert.ok(registry.length, `${testCase.name}: registry route returned no results`); - assert.ok(runtime.length, `${testCase.name}: runtime route returned no results`); - assert.equal(canonical[0].skill.skillName, testCase.top, `${testCase.name}: canonical top route`); - assert.equal(registry[0].skill.name, testCase.top, `${testCase.name}: registry top route`); - assert.equal(runtime[0].skill.name, testCase.top, `${testCase.name}: runtime top route`); - if (testCase.lifecycle) assert.equal(runtime[0].skill.lifecycle, testCase.lifecycle, `${testCase.name}: lifecycle`); - if (testCase.category) assert.equal(runtime[0].skill.category, testCase.category, `${testCase.name}: category`); - assert.ok(!testCase.disallowedTop?.includes(runtime[0].skill.name), `${testCase.name}: disallowed top route`); -} - -for (const testCase of readRouterEvalCases()) { - const routes = runtimeRoute(testCase.query, 8); - const names = routes.map((route) => route.skill.name); - const lifecycles = new Set(routes.map((route) => route.skill.lifecycle)); - if (testCase.expected_top_skill) { - assert.equal(names[0], testCase.expected_top_skill, `${testCase.suite}/${testCase.name}: top route`); - } - if (testCase.expected_any_skills?.length) { - assert.ok( - testCase.expected_any_skills.some((skill) => names.includes(skill)), - `${testCase.suite}/${testCase.name}: expected one of ${testCase.expected_any_skills.join(", ")}; got ${names.join(", ")}`, - ); - } - if (testCase.expected_lifecycles?.length) { - assert.ok( - testCase.expected_lifecycles.some((lifecycle) => lifecycles.has(lifecycle)), - `${testCase.suite}/${testCase.name}: expected lifecycle ${testCase.expected_lifecycles.join(", ")}`, - ); - } -} - -console.log("Route regression tests passed."); - -function readRouterEvalCases() { - return readdirSync(path.join(repoRoot, "evals")) - .filter((file) => file.endsWith("router-cases.json")) - .sort() - .flatMap((file) => JSON.parse(readFileSync(path.join(repoRoot, "evals", file), "utf8")).map((testCase) => ({ suite: file, ...testCase }))); -} diff --git a/test/runtime-workflow.test.mjs b/test/runtime-workflow.test.mjs deleted file mode 100644 index 89b635a9..00000000 --- a/test/runtime-workflow.test.mjs +++ /dev/null @@ -1,66 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync, mkdtempSync, readFileSync, readdirSync, rmSync } from "node:fs"; -import { spawnSync } from "node:child_process"; -import os from "node:os"; -import path from "node:path"; -import { repoRoot } from "../scripts/lib/productize.mjs"; - -const tmpRoot = mkdtempSync(path.join(os.tmpdir(), "productize-runtime-workflow-test-")); -const stateDir = path.join(tmpRoot, "state"); - -try { - const started = runJson(["bin/productize-workflow", "start", "--json", "Is this PMF for our freemium product?"]); - assert.ok(started.id, "workflow start must return id"); - assert.equal(started.status, "started"); - assert.equal(started.classification.product_stage, "PMF search"); - assert.equal(started.classification.artifact_mode, "diagnostic"); - assert.equal(started.routes[0].name, "product-market-fit-cycle"); - - assertFile(path.join(stateDir, "workflows", `${started.id}.json`)); - assertFile(path.join(stateDir, "session-log.jsonl")); - assertFile(path.join(stateDir, "routing-log.jsonl")); - assert.match(readFileSync(path.join(stateDir, "session-log.jsonl"), "utf8"), /workflow_started/); - assert.match(readFileSync(path.join(stateDir, "routing-log.jsonl"), "utf8"), /route_resolved/); - - const completed = runJson([ - "bin/productize-workflow", - "complete", - "--json", - "--id", - started.id, - "--status", - "completed", - "--artifact-type", - "PMF cycle diagnosis", - "--summary", - "Diagnosed PMF risks and next validation loop.", - "--context-summary", - "PMF context saved for follow-up.", - ]); - assert.equal(completed.status, "completed"); - assert.equal(completed.artifact_type, "PMF cycle diagnosis"); - assert.ok(completed.saved_context, "completed workflow should save context"); - - assert.match(readFileSync(path.join(stateDir, "artifact-log.jsonl"), "utf8"), /PMF cycle diagnosis/); - assert.match(readFileSync(path.join(stateDir, "completion-status.jsonl"), "utf8"), /completed/); - assert.ok(readdirSync(path.join(stateDir, "contexts")).some((file) => file.endsWith(".json"))); -} finally { - rmSync(tmpRoot, { recursive: true, force: true }); -} - -console.log("Runtime workflow tests passed."); - -function runJson(command) { - const result = spawnSync(process.execPath, command, { - cwd: repoRoot, - encoding: "utf8", - env: { ...process.env, PRODUCTIZE_STATE_DIR: stateDir }, - }); - const output = `${result.stdout || ""}${result.stderr || ""}`; - assert.equal(result.status, 0, `${command.join(" ")} failed\n${output}`); - return JSON.parse(result.stdout); -} - -function assertFile(file) { - assert.ok(existsSync(file), `Missing file: ${file}`); -} diff --git a/test/setup-host.test.mjs b/test/setup-host.test.mjs deleted file mode 100644 index fc3e9969..00000000 --- a/test/setup-host.test.mjs +++ /dev/null @@ -1,119 +0,0 @@ -import assert from "node:assert/strict"; -import { existsSync, mkdtempSync, readFileSync, rmSync, statSync } from "node:fs"; -import { spawnSync } from "node:child_process"; -import os from "node:os"; -import path from "node:path"; -import { repoRoot } from "../scripts/lib/productize.mjs"; - -const tmpRoot = mkdtempSync(path.join(os.tmpdir(), "productize-setup-host-test-")); - -try { - const installRoot = path.join(tmpRoot, "codex", "skills"); - const marketplacePath = path.join(tmpRoot, "codex", "plugins", "productize-skills.json"); - run([ - process.execPath, - "scripts/setup-host.mjs", - "--host", - "codex", - "--mode", - "copy", - "--force", - "--dest", - installRoot, - "--marketplace", - marketplacePath, - ]); - - assertFile(path.join(installRoot, "productize", "SKILL.md")); - assertFile(path.join(installRoot, "productize-product-market-fit-cycle", "SKILL.md")); - - const runtimeRoot = path.join(path.dirname(installRoot), "productize"); - const runtimeManifest = JSON.parse(readFileSync(path.join(runtimeRoot, "runtime.json"), "utf8")); - assert.equal(runtimeManifest.host, "codex"); - assert.equal(runtimeManifest.skills_root, installRoot); - assert.ok(runtimeManifest.sidecars.includes("bin/productize-runtime.mjs")); - assert.ok(runtimeManifest.sidecars.includes("bin/productize-routing.mjs")); - assert.ok(runtimeManifest.sidecars.includes("bin/productize-workflow")); - assertFile(path.join(runtimeRoot, "bin", "productize-runtime.mjs")); - assertFile(path.join(runtimeRoot, "bin", "productize-routing.mjs")); - assertFile(path.join(runtimeRoot, "bin", "productize-skill-router")); - assertFile(path.join(runtimeRoot, "bin", "productize-workflow")); - assertFile(path.join(runtimeRoot, "registry", "skills.json")); - assertOwnerOnly(path.join(installRoot, "productize-product-market-fit-cycle", "SKILL.md")); - assertOwnerOnly(path.join(runtimeRoot, "registry", "skills.json")); - assertExecutableOwnerOnly(path.join(runtimeRoot, "bin", "productize-skill-router")); - assertExecutableOwnerOnly(path.join(runtimeRoot, "bin", "productize-workflow")); - - const marketplace = JSON.parse(readFileSync(marketplacePath, "utf8")); - assert.equal(marketplace.skills, installRoot); - - const router = spawnSync(process.execPath, [path.join(runtimeRoot, "bin", "productize-skill-router"), "Is this PMF?"], { - cwd: tmpRoot, - encoding: "utf8", - env: { ...process.env, PRODUCTIZE_STATE_DIR: path.join(tmpRoot, "state") }, - }); - const routerOutput = `${router.stdout || ""}${router.stderr || ""}`; - assert.equal(router.status, 0, routerOutput); - assert.match(routerOutput, /^product-market-fit-cycle\t/m); - - const noPrefixRoot = path.join(tmpRoot, "codex-no-prefix", "skills"); - const dryRun = run([ - process.execPath, - "scripts/setup-host.mjs", - "--host", - "codex", - "--mode", - "copy", - "--dry-run", - "--no-prefix", - "--dest", - noPrefixRoot, - ]); - assert.match(dryRun.stdout, /productize-product-market-fit-cycle.+product-market-fit-cycle/); - assert.match(dryRun.stdout, /productize-routing\.mjs/); - - run([process.execPath, "bin/productize-config", "set", "skill_prefix", "false"]); - const savedPreferenceDryRun = run([ - process.execPath, - "scripts/setup-host.mjs", - "--host", - "codex", - "--mode", - "copy", - "--dry-run", - "--dest", - path.join(tmpRoot, "codex-saved-prefix", "skills"), - ]); - assert.match(savedPreferenceDryRun.stdout, /productize-product-market-fit-cycle.+product-market-fit-cycle/); -} finally { - rmSync(tmpRoot, { recursive: true, force: true }); -} - -console.log("Setup-host tests passed."); - -function run(command) { - const result = spawnSync(command[0], command.slice(1), { - cwd: repoRoot, - encoding: "utf8", - env: { ...process.env, PRODUCTIZE_STATE_DIR: path.join(tmpRoot, "state") }, - }); - const output = `${result.stdout || ""}${result.stderr || ""}`; - assert.equal(result.status, 0, `${command.join(" ")} failed\n${output}`); - return result; -} - -function assertFile(file) { - assert.ok(existsSync(file), `Missing file: ${file}`); -} - -function assertOwnerOnly(file) { - if (os.platform() === "win32") return; - const mode = statSync(file).mode & 0o777; - assert.ok((mode & 0o077) === 0, `${file} must not be group/world accessible: ${mode.toString(8)}`); -} - -function assertExecutableOwnerOnly(file) { - if (os.platform() === "win32") return; - const mode = statSync(file).mode & 0o777; - assert.equal(mode, 0o700, `${file} must be owner-executable only: ${mode.toString(8)}`); -} diff --git a/test/setup-script.test.mjs b/test/setup-script.test.mjs deleted file mode 100644 index 16fce5fd..00000000 --- a/test/setup-script.test.mjs +++ /dev/null @@ -1,55 +0,0 @@ -import assert from "node:assert/strict"; -import { chmodSync, mkdirSync, mkdtempSync, rmSync, statSync, writeFileSync } from "node:fs"; -import { spawnSync } from "node:child_process"; -import os from "node:os"; -import path from "node:path"; -import { repoRoot } from "../scripts/lib/productize.mjs"; - -const tmpRoot = mkdtempSync(path.join(os.tmpdir(), "productize-setup-script-test-")); - -try { - const fakeBin = path.join(tmpRoot, "bin"); - mkdirSync(fakeBin, { recursive: true }); - const fakeCodex = path.join(fakeBin, "codex"); - writeFileSync(fakeCodex, "#!/usr/bin/env sh\nexit 0\n", { mode: 0o700 }); - chmodSync(fakeCodex, 0o700); - - const env = { - ...process.env, - PATH: `${fakeBin}${path.delimiter}${path.dirname(process.execPath)}${path.delimiter}${process.env.PATH || ""}`, - PRODUCTIZE_STATE_DIR: path.join(tmpRoot, "state"), - }; - - run(["./setup", "--dry-run", "--host", "auto"], env, /Hosts: codex/); - - run([process.execPath, "bin/productize-config", "set", "skill_prefix", "false"], env); - run(["./setup", "--dry-run", "--host", "auto"], env, /Skill prefix: flat/); - - const configPath = path.join(env.PRODUCTIZE_STATE_DIR, "config.json"); - const configMode = statMode(configPath); - assert.ok((configMode & 0o077) === 0, `config file must not be group/world readable: ${configMode.toString(8)}`); - - const help = run(["./setup", "--help"], env); - assert.match(help.stdout, /--host auto\|codex\|claude\|cursor\|opencode\|factory\|all/); - assert.match(help.stdout, /--dry-run/); -} finally { - rmSync(tmpRoot, { recursive: true, force: true }); -} - -console.log("Setup script tests passed."); - -function run(command, env = process.env, expectedStdout) { - const result = spawnSync(command[0], command.slice(1), { - cwd: repoRoot, - encoding: "utf8", - env, - }); - const output = `${result.stdout || ""}${result.stderr || ""}`; - assert.equal(result.status, 0, `${command.join(" ")} failed\n${output}`); - if (expectedStdout) assert.match(result.stdout, expectedStdout); - return result; -} - -function statMode(file) { - return os.platform() === "win32" ? 0o600 : statSync(file).mode & 0o777; -} diff --git a/test/skills_bundle_test.go b/test/skills_bundle_test.go new file mode 100644 index 00000000..64409dba --- /dev/null +++ b/test/skills_bundle_test.go @@ -0,0 +1,352 @@ +package test + +import ( + "bytes" + "fmt" + "io/fs" + "os" + "path/filepath" + "regexp" + "strings" + "testing" + + "github.com/itseffi/productize/internal/core/frontmatter" + "github.com/itseffi/productize/skills" +) + +func TestBundledSkillsExistAndUsePortableReferences(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + requiredPaths := []string{ + "skills/fix-reviews/SKILL.md", + "skills/final-verify/SKILL.md", + "skills/execute-task/SKILL.md", + "skills/execute-task/references/tracking-checklist.md", + "skills/create-prd/SKILL.md", + "skills/create-prd/references/prd-template.md", + "skills/create-prd/references/question-protocol.md", + "skills/create-prd/references/adr-template.md", + "skills/create-techspec/SKILL.md", + "skills/create-techspec/references/techspec-template.md", + "skills/create-techspec/references/adr-template.md", + "skills/create-tasks/SKILL.md", + "skills/create-tasks/references/task-template.md", + "skills/create-tasks/references/task-context-schema.md", + "skills/review-round/SKILL.md", + "skills/review-round/references/review-criteria.md", + "skills/review-round/references/issue-template.md", + } + + for _, relativePath := range requiredPaths { + t.Run(relativePath, func(t *testing.T) { + t.Parallel() + + absPath := filepath.Join(root, relativePath) + if _, err := os.Stat(absPath); err != nil { + t.Fatalf("expected %s to exist: %v", relativePath, err) + } + }) + } + + checkPortableContent(t, filepath.Join(root, "skills", "fix-reviews", "SKILL.md")) + checkPortableContent(t, filepath.Join(root, "skills", "execute-task", "SKILL.md")) + checkPortableContent(t, filepath.Join(root, "skills", "create-prd", "SKILL.md")) + checkPortableContent(t, filepath.Join(root, "skills", "create-techspec", "SKILL.md")) + checkPortableContent(t, filepath.Join(root, "skills", "create-tasks", "SKILL.md")) + checkPortableContent(t, filepath.Join(root, "skills", "review-round", "SKILL.md")) +} + +func TestBundledSkillFrontmatterParses(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + paths, err := filepath.Glob(filepath.Join(root, "skills", "*", "SKILL.md")) + if err != nil { + t.Fatalf("glob bundled skills: %v", err) + } + if len(paths) == 0 { + t.Fatal("expected bundled skills to exist") + } + + for _, skillPath := range paths { + skillPath := skillPath + t.Run(filepath.Base(filepath.Dir(skillPath)), func(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(skillPath) + if err != nil { + t.Fatalf("read %s: %v", skillPath, err) + } + + var metadata struct { + Name string `yaml:"name"` + Description string `yaml:"description"` + ArgumentHint any `yaml:"argument-hint,omitempty"` + } + if _, err := frontmatter.Parse(string(content), &metadata); err != nil { + t.Fatalf("parse frontmatter %s: %v", skillPath, err) + } + if metadata.Name == "" { + t.Fatalf("expected %s to define a non-empty name", skillPath) + } + if metadata.Description == "" { + t.Fatalf("expected %s to define a non-empty description", skillPath) + } + }) + } +} + +func TestIdeaForgeExtensionExistsAndUsesPortableReferences(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + requiredPaths := []string{ + "extensions/idea-forge/extension.toml", + "extensions/idea-forge/skills/idea-forge/SKILL.md", + "extensions/idea-forge/skills/idea-forge/references/adr-template.md", + "extensions/idea-forge/skills/idea-forge/references/advisors.md", + "extensions/idea-forge/agents/architect-advisor/AGENT.md", + "extensions/idea-forge/agents/stress-tester/AGENT.md", + "extensions/idea-forge/agents/pragmatic-engineer/AGENT.md", + "extensions/idea-forge/agents/product-mind/AGENT.md", + "extensions/idea-forge/agents/security-advocate/AGENT.md", + "extensions/idea-forge/agents/the-thinker/AGENT.md", + } + + for _, relativePath := range requiredPaths { + relativePath := relativePath + t.Run(fmt.Sprintf("Should contain %s", relativePath), func(t *testing.T) { + t.Parallel() + + if _, err := os.Stat(filepath.Join(root, relativePath)); err != nil { + t.Fatalf("expected %s to exist: %v", relativePath, err) + } + }) + } + + skillPath := filepath.Join(root, "extensions", "idea-forge", "skills", "idea-forge", "SKILL.md") + content, err := os.ReadFile(skillPath) + if err != nil { + t.Fatalf("read %s: %v", skillPath, err) + } + + var metadata struct { + Name string `yaml:"name"` + Description string `yaml:"description"` + } + if _, err := frontmatter.Parse(string(content), &metadata); err != nil { + t.Fatalf("parse frontmatter %s: %v", skillPath, err) + } + if metadata.Name != "idea-forge" { + t.Fatalf("expected extension skill name idea-forge, got %q", metadata.Name) + } + if metadata.Description == "" { + t.Fatalf("expected non-empty description in %s", skillPath) + } + + checkPortableContent(t, skillPath) +} + +func TestCreateTasksSkillDocumentsTaskTypeRegistryAndValidation(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + skillPath := filepath.Join(root, "skills", "create-tasks", "SKILL.md") + content, err := os.ReadFile(skillPath) + if err != nil { + t.Fatalf("read %s: %v", skillPath, err) + } + + text := string(content) + required := []string{ + "Read `.productize/config.toml`.", + "[tasks].types", + "`frontend`, `backend`, `docs`, `test`, `infra`, `refactor`, `chore`, `bugfix`", + "Run `productize tasks validate --name `.", + "Do not mark the skill complete until it exits 0.", + } + for _, snippet := range required { + if !strings.Contains(text, snippet) { + t.Fatalf("expected %s to include %q", skillPath, snippet) + } + } +} + +func TestTaskDocsOmitLegacyTaskFrontmatterKeys(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + legacyKeyPattern := regexp.MustCompile(`(?m)^[ \t]*(domain|scope):`) + + paths := []string{filepath.Join(root, "README.md")} + err := filepath.WalkDir(filepath.Join(root, "skills"), func(path string, d fs.DirEntry, err error) error { + if err != nil { + return err + } + if d.IsDir() { + return nil + } + paths = append(paths, path) + return nil + }) + if err != nil { + t.Fatalf("walk skills directory: %v", err) + } + + for _, path := range paths { + path := path + t.Run(filepath.ToSlash(strings.TrimPrefix(path, root+string(filepath.Separator))), func(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(path) + if err != nil { + t.Fatalf("read %s: %v", path, err) + } + if match := legacyKeyPattern.FindString(string(content)); match != "" { + t.Fatalf("expected %s to omit legacy task frontmatter keys, found %q", path, match) + } + }) + } +} + +func TestEmbeddedSkillsFSMatchesOnDisk(t *testing.T) { + t.Parallel() + + t.Run("Should match embedded skills filesystem with the filtered on-disk skills tree", func(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + source := filepath.Join(root, "skills") + sourceTree := snapshotTree(t, source) + + // Filter out non-skill files (embed.go, autoresearch artifacts, etc.) + wantTree := make(map[string]string, len(sourceTree)) + for p, content := range sourceTree { + if strings.HasSuffix(p, ".go") { + continue + } + if strings.Contains(p, "autoresearch-") { + continue + } + wantTree[p] = content + } + + embeddedTree := make(map[string]string) + err := fs.WalkDir(skills.FS, ".", func(p string, d fs.DirEntry, err error) error { + if err != nil { + return err + } + if d.IsDir() { + return nil + } + data, readErr := fs.ReadFile(skills.FS, p) + if readErr != nil { + return readErr + } + embeddedTree[p] = string(data) + return nil + }) + if err != nil { + t.Fatalf("walk embedded FS: %v", err) + } + + if len(embeddedTree) != len(wantTree) { + t.Fatalf("expected embedded FS to contain %d files, got %d", len(wantTree), len(embeddedTree)) + } + for p, wantContent := range wantTree { + gotContent, ok := embeddedTree[p] + if !ok { + t.Fatalf("expected embedded FS to contain %s", p) + } + if gotContent != wantContent { + t.Fatalf("expected embedded content for %s to match on-disk source", p) + } + } + }) +} + +func checkPortableContent(t *testing.T, path string) { + t.Helper() + + content, err := os.ReadFile(path) + if err != nil { + t.Fatalf("read %s: %v", path, err) + } + + text := string(content) + forbiddenSnippets := []string{ + ".claude/skills", + "pnpm run", + "scripts/read_pr_issues.sh", + } + for _, snippet := range forbiddenSnippets { + if strings.Contains(text, snippet) { + t.Fatalf("expected %s to omit %q", path, snippet) + } + } +} + +func TestSharedReferenceFilesAreIdentical(t *testing.T) { + t.Parallel() + + root := repoRoot(t) + + groups := [][]string{ + { + "skills/create-prd/references/adr-template.md", + "skills/create-techspec/references/adr-template.md", + "extensions/idea-forge/skills/idea-forge/references/adr-template.md", + }, + } + + for _, paths := range groups { + reference, err := os.ReadFile(filepath.Join(root, paths[0])) + if err != nil { + t.Fatalf("read %s: %v", paths[0], err) + } + + for _, p := range paths[1:] { + t.Run("Should keep "+p+" identical to "+paths[0], func(t *testing.T) { + t.Parallel() + + content, err := os.ReadFile(filepath.Join(root, p)) + if err != nil { + t.Fatalf("read %s: %v", p, err) + } + if !bytes.Equal(content, reference) { + t.Fatalf("expected %s to be identical to %s", p, paths[0]) + } + }) + } + } +} + +func snapshotTree(t *testing.T, root string) map[string]string { + t.Helper() + + snapshot := make(map[string]string) + err := filepath.WalkDir(root, func(path string, entry fs.DirEntry, err error) error { + if err != nil { + return err + } + if entry.IsDir() { + return nil + } + + relativePath, err := filepath.Rel(root, path) + if err != nil { + return err + } + content, err := os.ReadFile(path) + if err != nil { + return err + } + snapshot[filepath.ToSlash(relativePath)] = string(content) + return nil + }) + if err != nil { + t.Fatalf("snapshot %s: %v", root, err) + } + return snapshot +} diff --git a/tsconfig.base.json b/tsconfig.base.json new file mode 100644 index 00000000..66883d1d --- /dev/null +++ b/tsconfig.base.json @@ -0,0 +1,14 @@ +{ + "compilerOptions": { + "target": "ES2022", + "sourceMap": true, + "declaration": true, + "declarationMap": true, + "noUncheckedIndexedAccess": true, + "moduleDetection": "force", + "verbatimModuleSyntax": true, + "strict": true, + "esModuleInterop": true, + "skipLibCheck": true + } +} diff --git a/zsh/productize-completion/README.md b/zsh/productize-completion/README.md new file mode 100644 index 00000000..a56c4d6f --- /dev/null +++ b/zsh/productize-completion/README.md @@ -0,0 +1,52 @@ +# Productize Completion Plugin + +This plugin adds shell completion for `productize tasks run` so task slugs are completed from the +nearest `.productize/tasks` directory relative to your current working directory. + +## What it does + +- Completes `tasks` after `productize` +- Completes `run` after `productize tasks` +- Completes all directories under `.productize/tasks` after `productize tasks run` +- Works in worktrees and repository copies by scanning upward from `$PWD` until it finds `.productize/tasks` + +## Installation + +1. Copy the plugin file into your shell folder (already placed by default at: + `~/.zsh/productize-completion/productize-completion.plugin.zsh`). + + ```zsh + # if needed + cp /path/to/productize/zsh/productize-completion/productize-completion.plugin.zsh \ + "$HOME/.zsh/productize-completion/productize-completion.plugin.zsh" + ``` + +2. Source it from your `~/.zshrc`: + + ```zsh + if [[ -f "$HOME/.zsh/productize-completion/productize-completion.plugin.zsh" ]]; then + source "$HOME/.zsh/productize-completion/productize-completion.plugin.zsh" + fi + ``` + +3. Reload your shell: + + ```zsh + source ~/.zshrc + ``` + +## Quick usage + +From any Productize workspace: + +```zsh +cd /path/to/repo/.productize-task-root +productize tasks run +``` + +The command will suggest task directory names found in `.productize/tasks`. + +## Notes + +- Keep `.productize/tasks` present in the workspace root or an ancestor directory. +- If there are no tasks, completion will fall back to default zsh behavior for that command position. diff --git a/zsh/productize-completion/productize-completion.plugin.zsh b/zsh/productize-completion/productize-completion.plugin.zsh new file mode 100644 index 00000000..759bdd92 --- /dev/null +++ b/zsh/productize-completion/productize-completion.plugin.zsh @@ -0,0 +1,62 @@ +#!/usr/bin/env zsh + +# Finds the nearest .productize/tasks directory by walking up from the current +# working directory. +_productize_tasks_workspace() { + local dir="$PWD" + + while [[ -n "$dir" ]]; do + if [[ -d "$dir/.productize/tasks" ]]; then + print -r -- "$dir/.productize/tasks" + return 0 + fi + + [[ "$dir" == "/" ]] && break + dir="${dir:h}" + done + + return 1 +} + +# Provides zsh completion for: +# - `productize tasks` +# - `productize tasks run` +# - task slugs found under the discovered .productize/tasks directory +_productize() { + local -a comps + local tasks_path + local -a task_slugs + local task_path + + if (( CURRENT == 2 )); then + comps=(tasks) + compadd -Q -- "$comps[@]" + return 0 + fi + + if (( CURRENT == 3 )) && [[ $words[2] == "tasks" ]]; then + comps=(run) + compadd -Q -- "$comps[@]" + return 0 + fi + + if (( CURRENT >= 4 )) && [[ $words[2] == "tasks" ]] && [[ $words[3] == "run" ]]; then + tasks_path="$(_productize_tasks_workspace)" + + if [[ -n "$tasks_path" && -d "$tasks_path" ]]; then + task_slugs=() + for task_path in "$tasks_path"/*(N/); do + task_slugs+=("${task_path:t}") + done + + if (( ${#task_slugs} > 0 )); then + compadd -Q -a task_slugs + return 0 + fi + fi + fi + + return 1 +} + +compdef _productize productize