--- name: productize-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.