product-tracking-model-product

Name: product-tracking-model-product
Author: Accoil

24installs4forks

How to install product-tracking-model-product?

accoil/product-tracking-skills/product-tracking-model-product

$npx -y skills add Accoil/product-tracking-skills --skill product-tracking-model-product

Installs into the current project.

Summary

Build a structured product model by scanning the codebase and talking to the user. Produces .telemetry/product.md — a description of what the product does, who uses it, how value flows, and what entities exist. Use when starting telemetry work on a new codebase, when the user ask

Files · 1

View on GitHub

SKILL.md

1	# Model Product
2
3	You are a product telemetry engineer building a product model — a structured understanding of what the product does, who uses it, and how value flows. This model is the foundation for all later tracking decisions.
4
5	## Reference Index
6
7	\| File \| What it covers \| When to read \|
8	\|----------------------------------------\|---------------\|--------------\|
9	\| `references/principles.md` \| 15 core telemetry principles \| Justifying a design decision \|
10	\| `references/b2b-spec.md` \| Two-entity B2B model, group calls \| Working with accounts/organizations \|
11	\| `references/identity-and-groups.md` \| Identify/group patterns, when to call \| Designing entity model \|
12	\| `references/glossary.md` \| Terminology definitions \| Encountering unfamiliar terms \|
13	\| `references/group-hierarchy.md` \| Nested group structures \| Product has workspaces/projects/teams \|
14	\| `references/end-to-end-walkthrough.md` \| Complete Clipper example \| Seeing the full lifecycle in action \|
15
16	## Goal
17
18	Build a product model: a structured understanding of what the product does, who uses it, how value flows, and what entities exist. This model is the input to everything else — audit, design, implementation.
19
20	Output: `.telemetry/product.md`
21
22	## Prerequisites
23
24	None — this is the starting point. This phase has no upstream dependencies.
25
26	Folder initialization: If the `.telemetry/` folder doesn't exist, create it before writing any output:
27
28	```bash
29	mkdir -p .telemetry/audits
30	```
31
32	Then write the `.telemetry/README.md` file (see Output section below) to explain the folder's purpose.
33
34	## Discovery Process
35
36	This phase uses two sequential steps: a silent codebase scan followed by a focused conversation.
37
38	### 1. Silent Codebase Scan
39
40	Before asking any questions, perform a quick structural scan of the codebase. This is not an audit — you're not looking at tracking calls. You're inferring the product shape.
41
42	Scan for:
43	- README / docs — `README.md`, `docs/`, `CONTRIBUTING.md` → product purpose, architecture, key concepts. Read the project README first — it's the fastest path to understanding what the product does and how it's structured.
44	- Routes / pages — `routes.ts`, `pages/`, `app/`, URL patterns → feature areas
45	- Controllers / handlers — API endpoints → what the product does
46	- Models / schema — database models, migrations, Prisma/TypeORM schema → entities
47	- Jobs / workers — background processing → async workflows
48	- Mutations / actions — GraphQL mutations, server actions → user-initiated changes
49	- Auth / middleware — roles, permissions, multi-tenancy → entity model
50	- Package manifest — `package.json`, `Gemfile`, `requirements.txt` → tech stack and integrations
51
52	Build an inferred view:
53	- What entities exist? (users, accounts, projects, etc.)
54	- What are the main feature areas? (from routes/controllers)
55	- What workflows are there? (from jobs, mutations)
56	- What does the product likely do?
57
58	Do NOT:
59	- Read every file — scan patterns and names
60	- Look at tracking/analytics code — that's audit
61	- Spend more than 2-3 minutes on this pass
62	- Present raw findings to the user — synthesize first
63
64	### 2. Conversation with User
65
66	Use the inferred view to have a more informed conversation. You're not starting from zero — you have hypotheses to validate.
67
68	Key areas to cover:
69	- Product identity: category, primary value action, what failure looks like. Lead with what you inferred: "This looks like a [category] product that [does X]. Is that right?"
70	- Value mapping: core features (directly deliver value) vs supporting features (enable core). "What's the action that, if it dropped to zero, would mean the product has failed?"
71	- Entity model: how users/accounts/groups relate, roles, multi-tenancy. "I found models for [entities]. How do they relate?"
72	- Group hierarchy depth: "How many levels should we track? Most products benefit from 2-3 levels (e.g., Account → Workspace). Going deeper adds group() call complexity for diminishing analytical returns. Where should we draw the line?" Not all products have group hierarchy — B2C products may only need user-level tracking.
73	- Business model: monetization approach, pricing tiers (check for Stripe/billing code in Gemfile/package.json), free vs paid features. This matters for telem

People who liked this also viewed

6 picks

Type