# Product Competitor Analysis

> 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.

- **Type:** Skill
- **Install:** `agentstack add skill-atlasomnia-donna-starter-product-competitor-analysis`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [AtlasOmnia](https://agentstack.voostack.com/s/atlasomnia)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [AtlasOmnia](https://github.com/AtlasOmnia)
- **Source:** https://github.com/AtlasOmnia/donna-starter/tree/main/skills/product-competitor-analysis

## Install

```sh
agentstack add skill-atlasomnia-donna-starter-product-competitor-analysis
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [AtlasOmnia](https://github.com/AtlasOmnia)
- **Source:** [AtlasOmnia/donna-starter](https://github.com/AtlasOmnia/donna-starter)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-atlasomnia-donna-starter-product-competitor-analysis
- Seller: https://agentstack.voostack.com/s/atlasomnia
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.