product-competitor-analysis v1.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/79cc21815b0cd9a9.

---
name: product-competitor-analysis
description: product-competitor-analysis — Conduct codebase-grounded competitive assessments for iOS/macOS apps by inventorying implemented behavior, mapping user needs, extracting differentiators, identifying blockers, and producing a positioning summary with line-grounded evidence.
version: 1.0.0
author: Nous Research
license: MIT
platforms:
- macOS
- iOS
metadata:
 category: software-development
 tags:
 - competitive-analysis
 - product-readiness
 - architecture-review
 - localization
 - security
 related_skills:
 - source-verification
 - specification-compliance-review
 - hermes-self-evaluation
---
# 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