Competitive Analysis Scope - AFPS Tracker
Proposed Scope
The proposed run is standard-mode competitive analysis for AFPS Tracker, scoped to the first active product path in research/.progress.yaml: research/afps-tracker.
The scope should compare AFPS Tracker against workaround bundles and adjacent tools used by AFPS or AFPS-like operators to understand research-stage workflow state, branch status, evidence provenance, and agent handoff context.
Mode
ICP exists and defines the competitive frame.
Research Target
Companion map over AFPS research portfolio state.
Canonical Scope
research/afps-tracker, not flat repository mode.
Known Product Context
| Context Item | Observed Scope Evidence | Implication For Competitive Research |
|---|---|---|
| Product | AFPS Tracker is a companion sync layer for the alignment-first, prototype-second workflow. | Research should evaluate tools that map, preserve, or duplicate workflow state. |
| Primary ICP | AFPS power users and AI workflow operators running repo-local research workflows. | The competitive frame should prioritize operator workflows, not broad enterprise PM purchasing. |
| Core job | Keep product paths, evidence, approval state, and next actions understandable across many generated artifacts. | Compare current alternatives by state fidelity, provenance, and repeated review ergonomics. |
| Non-goals | Not generic project management, not a recommender, and not development execution tracking. | Keep build/execution control-plane tools as adjacent alternatives, not the main category unless evidence supports overlap. |
| Codebase state | No app source, README, or package manifest is present in this checkout. | Competitive research should be product-research-led rather than implementation-led. |
Framework Selection
Proposed framework set: all four competitive-analysis child frameworks. The first three are always defaulted by this orchestrator. Strategic group mapping is included because the ICP research names multiple alternative categories and buyer contexts.
| Order | Step After Approval | Purpose |
|---|---|---|
| 1 | $competitive-analysis/frameworks/porter-five-forces | Industry structure and competitive pressure. |
| 2 | $competitive-analysis/frameworks/swot | Evidence-grounded opportunity and risk scan. |
| 3 | $competitive-analysis/frameworks/strategic-group-map | Cluster alternatives by market axes and identify whitespace. |
| 4 | $competitive-analysis/frameworks/feature-pricing-matrix | Compare capabilities, pricing, packaging, and proof points. |
| 5 | $competitive-analysis --synthesize | Combine approved framework outputs into canonical competitive analysis. |
Source Plan
After scope approval, framework execution should use web search extensively and cite every competitor fact from search results. Pre-approval discovery found source categories, not conclusions.
| Source Category | Planned Evidence | Why It Matters |
|---|---|---|
| Competitor and alternative homepages | Product pages for manual repo workflows, PM tools, research repositories, and agent workflow tools. | Identifies actual value propositions and category language. |
| Pricing and packaging pages | Published plans, free tiers, creator seats, maker seats, enterprise gates. | Grounds feature/pricing comparisons in current public offers. |
| Docs and integration pages | Git, repo, issue tracker, AI-agent, collaboration, and export/integration support. | Shows whether alternatives can preserve AFPS source fidelity. |
| User sentiment and community discussions | Recent forum, review, social, or community evidence around context loss, source of truth, and research repository pain. | Separates vendor claims from operator pain language. |
| Recent activity | Launch notes, changelogs, release pages, announcements, and product updates from the last 12 months where available. | Captures current movement in AI workflow and product discovery categories. |
| Repo artifacts | Approved idea brief, ICP, progress manifest, alignment pages, and task history. | Keeps competitor analysis aligned to AFPS Tracker's actual scope. |
Output Paths
| Artifact | Path | Timing |
|---|---|---|
| Scope review page | alignment/competitive-analysis-afps-tracker.html | Created in Stage 1 for approval. |
| Stage 2 working packet | research/afps-tracker/_working/preliminary-competitive-analysis-research.md | Create only after scope approval. |
| Framework outputs | research/afps-tracker/competitive-analysis-*.md | Create through approved framework subskills. |
| Canonical synthesis | research/afps-tracker/competitive-analysis.md | Create only after synthesis artifact approval. |
| Search log | research/afps-tracker/competitive-analysis-search-log.md | Create with canonical synthesis approval. |
| Execution queue | tasks/todo.md | Queue framework steps only after this scope is approved. |
Scope Evidence Matrix
| Claim For Scope | Evidence | Inference | Confidence | Decision Impact |
|---|---|---|---|---|
| Use product-path mode. | research/.progress.yaml lists research/afps-tracker first in active_paths. | The skill prerequisite says standard-mode competitive analysis scopes to the first active path by default. | High | Research outputs should live under research/afps-tracker/. |
| Use standard mode, not concept validation. | research/afps-tracker/icp.md exists and defines a primary ICP. | The competitive frame is mature enough to compare alternatives for a defined operator audience. | High | No concept-description question is needed before scope approval. |
| Include strategic group mapping. | ICP lists alternatives across manual repo navigation, PM tools, product discovery tools, research repositories, and agent workflow tools. | The landscape spans multiple categories and buyer/user assumptions. | Medium | Approve or reject the optional strategic-map lane explicitly. |
| Research should be product-research-led. | Repository has no app source, README, or package manifest. | There is no implementation surface to compare; the approved research artifacts are the product source of truth. | High | Source plan should emphasize market pages, pricing, user sentiment, and existing research. |
Assumptions And Gaps
| Assumption Or Gap | Status | What Would Change It |
|---|---|---|
| AFPS Tracker's direct competitors may be workaround bundles rather than named products. | Provisional | Search evidence finds direct AFPS-like tracker products. |
| Agent execution tools are adjacent, not core competitors. | Provisional | Evidence shows operators use them primarily to track research-stage branch and evidence state. |
| Pricing comparison may rely on adjacent categories because AFPS-specific WTP is unproven. | Known gap | Direct buyer interviews or public pricing for comparable AFPS workflow tools. |
| Exec Loop Tracker remains out of scope. | High confidence | User approval explicitly expands this analysis into cross-path development tracking. |
Approval Record
| Gate | Approved Answer | Result |
|---|---|---|
| Scope and non-goals | Approve AFPS Tracker-only competitive scope | Keep exec-loop-tracker out of scope. |
| Framework set | Approve all four frameworks: porter-five-forces, swot, strategic-group-map, feature-pricing-matrix | Queue all four framework child skills. |
| Evidence coverage | Approve the source plan as sufficient for Stage 2 | Use the approved source categories during framework research. |
| Artifact destination | Approve product-path destinations and post-approval task queueing | Use research/afps-tracker outputs and update tasks/todo.md. |
Approval Gates
Scope And Non-Goals
Should Stage 2 research target AFPS Tracker only, keeping Exec Loop Tracker and development execution tracking out of scope?
Framework Set
Which framework set should be queued after scope approval?
Evidence Coverage
Is the planned source coverage sufficient for Stage 2 framework research?
Artifact Destination And Proposed File Changes
Do you approve the product-path output destinations and the rule that framework tasks are queued only after this scope is approved?
Compile YAML
Use feedback-only YAML for revision requests before answering every gate. Use final compiled answers when ready to approve or redirect the scope.
Answer all required gate questions to compile final answers.