competitive-analysis

Competitive Analysis

Overview

Systematic comparison of the dev-team plugin against another plugin, tool, feature set, or idea. The goal is to surface gaps, weaknesses, and improvement opportunities — then produce rough specs for closing each gap.

This skill is analytical first, generative second. It catalogs what both sides offer, identifies where dev-team falls short, and then drafts actionable specs for each gap. The analysis should be honest — if the other plugin does something better, say so plainly.

Input Sources

The comparison target can come in several forms. Determine which applies and gather the data accordingly:

Source	How to gather
URL (repo, docs, marketplace)	Fetch the URL. Look for README, CLAUDE.md, plugin manifests, agent/skill/command directories. If the repo is large, focus on the manifest, README, and directory listing first.
Local path	Read the directory structure, then key files (README, CLAUDE.md, manifests, agent/skill dirs).
Pasted description or feature list	Use as-is. Ask clarifying questions only if the description is too vague to compare against.
Concept or idea	Treat as a hypothetical plugin with the described capabilities. Note in the report that the comparison is against an idea, not a shipped product.

Analysis Framework

Step 1: Catalog dev-team

Read knowledge/agent-registry.md for the full inventory. Organize into these capability layers:

• Team agents — roles and primary focus areas
• Review agents — what code quality aspects are covered
• Skills — reusable knowledge modules
• Commands — user-invocable workflows
• Templates — language/framework-specific scaffolding
• Knowledge files — progressive-disclosure reference data
• Hooks — automated guards and triggers
• Workflows — multi-phase orchestration (Research → Plan → Implement)

Step 2: Catalog the comparison target

Map the other plugin's capabilities into the same layers where possible. Not every plugin will have all layers — that's fine. For capabilities that don't map cleanly, create an "Other" category and describe them.

For each capability, note:

• What it does (one line)
• How mature it appears (shipped, experimental, documented but not implemented)
• Whether dev-team has an equivalent

Step 3: Gap analysis

Compare layer by layer. For each gap, classify it:

Classification	Meaning
Missing (dev-team)	The other plugin has this; we have nothing equivalent
Weaker (dev-team)	We have something similar, but the other plugin's version is more capable or better designed
Different approach	Both plugins address this need, but with fundamentally different strategies worth examining
Stronger (dev-team)	We do this better (include these for balance — the report should be honest in both directions)

Focus the gap analysis on things that matter. A missing agent for an obscure framework isn't as important as a missing workflow capability. Use judgment about what would actually improve the plugin if addressed.

Always write the classification with the (dev-team) qualifier in every table cell — never the bare word alone. "Stronger" and "Weaker" are meaningless out of context to a reader scanning a single row without the legend in view; "Missing (dev-team)" and "Stronger (dev-team)" are unambiguous on their own. Different approach needs no qualifier since it doesn't imply a direction.

Step 4: Rough specs for gaps

For each Missing or Weaker gap, produce a rough spec:

### Gap: [Name]

**Classification**: Missing (dev-team) | Weaker (dev-team)
**Layer**: Agent | Skill | Command | Workflow | Hook | Template | Knowledge
**Priority**: High | Medium | Low

**What the other plugin does**:
[1-2 sentences]

**What we have now** (if Weaker):
[What exists and why it falls short]

**Proposed addition**:
- **Type**: [agent / skill / command / hook / template]
- **File**: [proposed file path]
- **Description**: [What it would do — 2-3 sentences]
- **Dependencies**: [What existing components it would interact with]
- **Estimated complexity**: [Small / Medium / Large]
- **Model tier**: [haiku / sonnet / opus — if applicable]

For Different approach items, don't write a spec — write a short analysis of tradeoffs instead, so the reader can decide whether to adopt the alternative approach.

Step 5: Prioritization

After listing all gaps, rank the top 5 by impact. Impact considers:

• How many users would benefit
• How fundamental the capability is (workflow > convenience)
• How much effort it would take relative to the value (quick wins first)
• Whether it addresses a real limitation vs. a nice-to-have

Output Format

Write the report to .dev-team-reports/competitive-analysis-<date>.md using this structure.

For the header block and closing Provenance section, follow knowledge/report-template.md; the sections below are this skill's own body.

(Date, Target, Tool versions, and Scope come from that shared header — Tool versions renders _Not applicable — no tool version applies to a comparison._ per the empty-section rule; Source type has no shared-contract equivalent and stays as this skill's own field.)

# Competitive Analysis: dev-team vs [Target]

**Date**: <date>
**Target**: [Name, URL, or description of what was compared]
**Tool versions**: _Not applicable — no tool version applies to a comparison._
**Scope**: [Layers/capabilities compared]
**Source type**: URL | Local path | Description | Concept

## Executive Summary

[2-3 sentences: what was compared, how many gaps found, top finding]

## Capability Comparison

### [Layer Name]

| Capability | dev-team | [Target] | Classification |
|-----------|-----------------|----------|----------------|
| ...       | ...             | ...      | Missing (dev-team) / Weaker (dev-team) / Different approach / Stronger (dev-team) |

[Repeat for each layer that has differences]

## Gap Specs

[One spec block per Missing or Weaker gap, using the template from Step 4]

## Different Approaches Worth Examining

[Short tradeoff analysis for each Different Approach item]

## Our Strengths

[Brief list of areas where dev-team is stronger — keeps the report balanced]

## Top 5 Priorities

| Rank | Gap | Layer | Complexity | Why |
|------|-----|-------|-----------|-----|
| 1    | ... | ...   | ...       | ... |

## Next Steps

[Concrete recommendations: which gaps to address first, any quick wins, things that need more research]

## Provenance

- Repository: `<repo path>`
- Branch / SHA: `<branch>` / `<sha>`
- Run parameters: `<flags>`
- `dev-team` plugin version: `<plugin_version>`

Presenting Results

After writing the report, display in chat:

1. The file path
2. The executive summary
3. The top 5 priorities table

Do not repeat the full report in chat.