Technical Intent Parser

Contributed by: Mark Whaley · Source: PM Starter Kit

Use this when a PM needs to bridge the gap between product language and engineering architecture. Takes a feature name, description, and acceptance criteria and decomposes them into structured technical signals — systems, services, data entities, UI components, backend actions, and event triggers — that downstream analysis skills can reason about.

This skill is the entry point for the Feature Impact Radar pipeline: /technical-intent-parser → /architecture-context-reviewer → /repository-discovery → /codependency-analyzer.

Process

Step 1: Gather inputs

Ask the user:

1. Feature name — A short name for the feature or capability.
2. Feature description — What the feature does, in product language.
3. Acceptance criteria (REQUIRED) — The conditions that must be true for the feature to be considered complete. If acceptance criteria are missing, stop and request them before proceeding.
4. User flow (optional) — If available, the step-by-step interaction the user follows.

Step 2: Identify which personas are affected

Before generating the intent model, prompt the user:

Persona check: Which user persona(s) does this feature serve? If you have defined personas (e.g., from /persona-create or /persona-draft), name them. If not, describe the key user types briefly.

This grounds the decomposition in real user context and ensures the technical signals map to actual user outcomes, not just system internals.

Step 3: Identify systems involved

Map the feature to logical system domains implied by the description and acceptance criteria. Only include systems clearly implied by the request — do not invent systems.

Common system domains:

• authentication, billing, notifications, search, payments, user profile, messaging, analytics, scheduling, content management

Step 4: Identify data entities, UI components, backend actions, and event triggers

For each category, extract what the feature implies:

Data entities — Business objects mentioned or implied (e.g., user, order, invoice, subscription, reminder, document).

UI components — User-facing surfaces affected (e.g., settings page, dashboard widget, notification panel, form, modal). Only include if the feature explicitly involves user interaction.

Backend actions — Core system responsibilities required to satisfy the acceptance criteria (e.g., create, update, retrieve, schedule, validate, authorize, send, process, store).

Event triggers — Signals that imply asynchronous behavior (e.g., due date reached, user action, scheduled job, system state change, webhook). Events often drive cross-service dependencies.

Step 5: Produce the technical intent model

Present the structured output:

## Technical Intent Model — (Feature Name)

**Date:** (Date)
**Persona(s):** (Persona names from Step 2)

---

### Systems Involved
- (System domain 1)
- (System domain 2)

### Possible Services
- (Candidate service 1 — kebab-case, e.g., billing-service)
- (Candidate service 2)

### Data Entities
- (Entity 1)
- (Entity 2)

### UI Components
- (Component 1)
- (Component 2)

### Backend Actions
- (Action 1)
- (Action 2)

### Event Triggers
- (Trigger 1)
- (Trigger 2)

Step 6: Review and validate

Ask the user:

• Does this decomposition match your understanding of the feature?
• Are there systems or entities I missed?
• Do the event triggers capture the async behavior you expect?
• Ready to proceed to /architecture-context-reviewer with these signals?

Adjust as needed.

Related skills

• /architecture-context-reviewer — next step: retrieve verified architecture context for the systems and entities identified here.
• /repository-discovery — maps verified services to code repositories and maintainers.
• /codependency-analyzer — extracts evidence-based dependencies from the identified codebases.
• /prd-draft — when you need to write the PRD that defines the feature this skill decomposes.
• /story-write — when you're ready to write stories after the full impact analysis.

Output location

Present the technical intent model as formatted text in the conversation. The output feeds directly into /architecture-context-reviewer and downstream pipeline skills. The user may also copy it into planning documentation or feature briefs.