AFPS Tracker — Idea Brief (Alignment Review)

AFPS Tracker is a companion sync layer for users of the alignment-first, prototype-second (AFPS) skills workflow.from prompt It reads and writes the state the workflow already emits — primarily research/.progress.yaml (product_paths[]), skill outputs, and alignment pages — and presents a single navigable surface that shows, for a portfolio of concepts, both (a) the branching tree of product paths that research throws off and (b) each branch's progression through the skill pipeline stages.inferred

It is a passive map: it faithfully visualizes current state without recommending next actions or nagging.from prompt Scope ends where research ends — at the moment a branch is promoted to build. Development tracking is explicitly out of scope for AFPS Tracker and is recorded separately as exec-loop-tracker, a parallel active concept.

The AFPS workflow already generates rich branching state, but it is scattered across YAML, markdown briefs, interview logs, and HTML alignment pages in nested folders.from repo There is no single surface to answer: where is every concept in the pipeline, which branches are alive / parked / deferred / dead, why each branch exists, and what evidence backs it.inferred

As exploration fans out — multiple ICPs, problems, and market gaps per concept; multiple concepts per portfolio — breadth becomes hard to hold in one's head. The operator loses the ability to reason about the whole exploration as a portfolio and to decide where to commit compute.from prompt

Primary: users of the AFPS skills workflow — operators running research-first, agentic product discovery with this specific skill pack.from prompt The concept author is the first user (dogfooding).

It is not scoped as a generic PM tool for arbitrary teams; the wedge is tight coupling to the AFPS workflow's data and stages.inferred

A workflow-state and branching-decision visualizer for an agentic research pipeline — a companion "map" over the AFPS skills system.inferred

Kanban is one candidate UX, but the two-dimensional model (branch tree × pipeline stages) may suit a tree/graph or portfolio-dashboard view better. UX form is deliberately undecided and deferred to later UX skills.from prompt

Purpose-built for the AFPS workflow: it understands skill stages, product-path branching, and the status / reason / evidence_refs / revisit_trigger / next_skill fields, plus alignment artifacts.from repo

Generic kanban/PM tools (Trello, Linear, Notion) are workflow-agnostic and cannot represent skill-stage progression, research-driven branching, or the link between a branch and its supporting evidence. By syncing the workflow's own emitted state, the tracker turns scattered artifacts into one portfolio map with near-zero manual data entry.inferred

• Companion/sync layer: must read and write research/.progress.yaml and coexist with skill-produced files without corrupting them.from prompt
• Multi-concept portfolio: one instance spans many concepts/product lines, each with its own branch tree (aligns with /product-line review).from prompt
• Passive: visualization and editing of state — no recommendation engine or nudges in v1.from prompt
• Research-phase only: stops at branch-promoted-to-build; no build/dev progress modeling.from prompt
• Pre-defined data model: product_paths[] fields (id, label, source_skill, scope_path, status, reason, evidence_refs, revisit_trigger, next_skill, pipeline_stage, last_touched) and active_paths.from repo
• Project state: .agents/project.json marks this as a business-app with business-discovery enabled; direct-to-primary git flow; no GitHub Actions by default.from repo

• Not a generic project/task management tool.
• Not an active guide / recommender / notifier in v1 (passive map only).
• Not a development/execution tracker — that is tracked as the separate parallel active concept exec-loop-tracker.
• Not a replacement for the skills themselves; it does not run skills, it reflects their state.
• Not (yet) a multi-user team-collaboration SaaS.

• inferred The pain of scattered state is real and acute enough to warrant a dedicated tool vs. reading files directly. (Test in ICP/problem research.)
• inferred .progress.yaml is the authoritative state source and is populated consistently across skills. (Verify how reliably skills emit it.)
• inferred Two-way sync (write-back) is desired and safe; the alternative is read-only viewing. (Open: confidence in writing to workflow files.)
• open Whether other AFPS users exist in meaningful numbers, or whether this is effectively a tool-of-one for now. (ICP question.)
• open How concepts map to "product lines" — is a product line a tag/grouping over concepts, or a distinct first-class object?
• open Delivery form (local app reading repo files? hosted? IDE/Claude Code panel?) — implementation, deferred.
• open The parallel exec-loop-tracker concept still needs its own idea-scope pass before ICP or implementation planning.

Ready for /icp.

Inputs /icp should use: this brief's beneficiary hypothesis (AFPS-workflow operators), the value wedge (workflow-coupled portfolio map), and the dogfooding context (author is user #1).

Assumptions to test first:

1. How many real AFPS-workflow users exist beyond the author, and whether their pain matches.
2. Whether scattered-state pain is acute enough to adopt a dedicated tool.
3. Whether passive visualization is sufficient or users expect active guidance.

Primary: /icp research/afps-tracker — business-discovery is already enabled in .agents/project.json, so the approved install route is satisfied and ICP can run against the AFPS-workflow operator audience.

Scope exec-loop-tracker separately before researching that development-stage product path.

• Read-only viewer (rejected for v1): lower risk, no write-corruption danger, but user explicitly wanted a sync layer that edits state. Kept as a fallback if write-safety proves hard.
• Standalone re-model (rejected): its own data store decoupled from workflow files. Rejected because it would duplicate state and break the near-zero-data-entry wedge.
• Active guide / recommender (deferred): surfaces next_skill, flags due revisit_triggers. User chose passive for v1; this is a natural v2 direction.
• Kanban-as-the-model (deferred to UX skills): kanban is one rendering; the branch-tree × stage model may favor a tree/graph view. UX form intentionally unfixed.
• Single-concept instance (rejected): simpler, but user wanted a multi-concept portfolio to manage a product line.
• Extend an existing PM tool (Linear/Notion) (rejected as wedge): workflow-agnostic; can't represent skill stages, branching, or evidence links.

• No market/competitor evidence — by design; this is pre-ICP. Owned by downstream research skills.
• No user-base sizing — unknown how many AFPS-workflow operators exist. Highest-priority gap for /icp.
• No reliability audit of .progress.yaml — not yet confirmed how consistently skills emit/maintain it. Verify before committing to two-way sync.
• No delivery-form exploration — local app vs. hosted vs. IDE panel; intentionally deferred to architecture.
• "Product line" definition unresolved — grouping vs. first-class object; flag for ICP/value-prop.

Round 0 — Initial idea (verbatim intent)

Explore a kanban product built around the alignment-first, prototype-second skills workflow. Guide research and then development by tracking progress through the various skills of the workflow and potential branching paths that arise from research. Different branches can evaluate different product opportunities which together constitute a product line; branches can arise from different ICPs discovered, problems discovered in research, or competitive analysis showing market gaps. Aim: explore all potential paths in research, then execute on fruitful branches. It doesn't have to be kanban as task management — UX variations are a later implementation decision/exploration.

Round 1

Round 2