Product Competitor Analysis

What this skill covers

Use this skill when asked to compare a local app/product to mainstream alternatives from local evidence only (or with explicit permission to use external research). It is intentionally structured for code-first competitive assessments where output should cite files, line ranges, and concrete implementation details.

Core principle

Every claim in the final analysis must be traceable to one of:

• concrete local code artifacts (files + line ranges)
• local config/docs
• command output that is itself grounded in local files

Category separation: native integration versus standalone replacement

When comparing an in-host integration to a standalone AI application, classify the products before scoring features. Do not treat “AI edits Office files” as the category; distinguish:

• Standalone replacement: owns its document, spreadsheet, or presentation engine; typically wins on convenience, breadth, cross-platform independence, and zero host-app requirements.
• Native integration: operates against the live host application's object model; can win on active-document context, fidelity to existing business files, in-place workflows, and verified host mutations, but carries more installation and compatibility complexity.

State the customer segment explicitly. A native integration is not universally superior: it is materially stronger for customers already dependent on the host application and its existing templates, while a standalone replacement may be better for users seeking an Office alternative. Avoid declaring a moat from architecture alone; translate the difference into an observable before/after workflow and identify the host-acceptance, onboarding, and reliability gates required to make the advantage real.

For this comparison pattern, apply the comparison framework in this skill.

Preflight

Before analysis:

1. Confirm target slice and language scope (e.g., iOS, macOS, CLI).
2. Confirm whether external validation is allowed.

• If user says “no web research” (or equivalent), perform conceptual only comparisons against mainstream categories.

3. Capture project shape first (top-level files, app layers, active targets).
4. Identify authoritative README(s), architecture notes, and build metadata.

Required evidence buckets

Collect evidence in these buckets and keep each bucket grounded:

• Feature inventory
• UI controls and state toggles
• Runtime states/lifecycle
• Input/output pipelines
• Persisted settings and storage
• User/jobs-to-features mapping
• Map likely jobs-to-be-done to concrete paths and controls
• Separate “implemented in code today” vs “present in docs only”
• Differentiators
• What the app does materially differently from baseline competitors
• Include provider architecture, route controls, feedback loops, anti-echo handling, etc.
• Missing table-stakes
• Compare against mainstream competitor categories to identify must-haves absent here
• Security / distribution blockers
• Secrets handling, key material pathways, packaging risks
• Permissions and entitlement impacts
• Store/review/readiness gaps
• UX/reliability risks
• failure states visible to users
• onboarding and setup friction
• session lifecycle interruptions
• Positioning
• A concise 1–2 sentence positioning for store/market fit

Evidence format

For every major claim, include:

• file path + line range
• short phrase describing what is observed
• confidence level (implemented, partial, docs-only, inferred)

Standard execution flow

1) Discover layout and project shape

Use local discovery only:

• app entrypoint(s)
• domain folders (App/Providers/Audio/Resources)
• runtime entry config (project.yml, .xcscheme, Info.plist)

2) Inventory implementation

Extract the following types first:

• status/state enums
• provider protocol + implementations
• session manager/view model
• audio capture and routing layer
• key settings/state persistence mechanisms

3) Produce analysis sections in fixed order

Use this section order in final response:

1. Feature inventory
2. Target users + use cases
3. Differentiators
4. Missing table-stakes features
5. Security/distribution blockers
6. UX risks
7. Overall positioning
8. Confidence/risk callouts

4) Keep comparisons constrained when requested

If user says no web research:

• do conceptual benchmarking only
• avoid naming external products as facts unless user supplied
• do not cite ungrounded feature claims

5) Close with concise verdict

End with a short, non-hedged “where this ships well today” vs “what must ship before broad consumer release”.

Strong constraints

• Do not assert unsupported metrics (latency, MAU, retention) without evidence from test artifacts.
• Avoid inventing competitor feature details from memory.
• Keep line-citation references consistent across the report.
• If a required evidence bucket is empty, call that explicitly and avoid padding.

Pitfalls

• Comparing platform-specific behavior to unrelated desktop behavior without separating targets.
• Mixing docs and runtime evidence as equivalent.
• Forgetting direct dependency on permissions (microphone, audio routes, background modes).
• Ignoring production security posture and focusing only on functional parity.

Deliverable template

Feature inventory

• [feature] – [evidence]

Use cases

• [persona/use case] – [mapped controls/settings]

Differentiators

• [claim] – [mechanism / path]

Missing table-stakes

• [feature gap] – [impact + priority]

Security & distribution

• [risk] – [where implemented or missing]

UX risks

• [risk] – [user-facing consequence]

Positioning

• [1–3 sentence positioning + likely store category]

Reuse assets

• : compact checklist + session examples for quick copy-paste.

Validation checklist

• At least 5 evidence citations across at least 2 feature domains
• At least one distribution/security block identified if credentials are user-provided in-app
• At least one clear non-negotiable blocker and one “nice-to-have but not blocking” item
• No uncited claim in final report