competitor-analysis-workflow

name	competitor-analysis-workflow
description	Use when the user wants to run, standardize, or update a cross-industry competitor analysis, benchmark, product comparison, or evidence-backed research report from scattered files, URLs, and notes.

Competitor Analysis Workflow

Turn scattered materials into a traceable, comparable, publication-ready competitor analysis.

Start

1. Read references/workflow-spec.md for the full operating sequence.
2. Read references/project-config-template.md when starting a project or when the user gives new scope, audience, output, or comparison requirements.
3. Inspect the project root and preserve existing user files, baselines, and unrelated changes.
4. Determine the requested mode: plan, collect, verify, map, compare, assets, outline, draft, review, release, or update.
5. Use the default profile when the user has not specified otherwise: standard depth, formal report, evidence-first, source register, internal traceability, and version-preserving edits.

Run

Follow the phases in references/workflow-spec.md in order. Do not draft decisive claims before the relevant evidence records exist.

• For collect or verify, read references/source-register-template.md and references/fact-register-template.md.
• For map or draft, read references/evidence-matrix-template.md.
• For compare, read references/comparison-matrix-template.md.
• For assets, read references/asset-register-template.md.
• For outline or draft, read references/report-outline-template.md.
• For review, read references/qa-checklist.md and return findings before changing files unless the user also requests fixes.
• For release, read references/release-checklist.md and update only the selected version.

At late checkpoints, show a concise status summary, key gaps, recommendations, and links to produced files. Ask a question only when the answer would materially change scope, comparison logic, output format, or a high-impact claim. Keep unresolved items in the project records rather than silently filling them with assumptions.

Branching Rules

• If the user asks for a plan only, stop after the brief, comparison framework, source plan, and proposed artifacts.
• If the user asks for a review only, do not edit the reviewed files.
• If a source is inaccessible, try an alternate authoritative path, record the failure, and do not infer the missing content.
• If sources conflict, preserve the conflict with scope and date context; do not silently merge the claims.
• If a claim lacks direct support, narrow the claim, mark it unresolved, or return to source collection.
• If a generated visual depicts a product, interface, parameter, or measured result, replace it with a source asset or label it as a concept; never present invented detail as a source fact.
• Preserve the baseline by default. Use versioned report and asset names for revisions, and update references atomically.

Completion Criteria

A run is complete only when:

• the scope and comparison dimensions are recorded;
• key sources are registered and their status is known;
• important facts and claims are traceable to exact source locations;
• comparison entries use compatible definitions and units;
• every table or figure has a purpose, caption, origin, and report location;
• the report has passed content, data, source, visual, language, and delivery checks;
• the final files, supporting records, and change log are versioned together.

If the work is incomplete, report the exact open items and the next required action instead of claiming completion.