/product

name: product
description: Apply product thinking to platform work — DevEx audits, friction analysis, RFC/ADR drafting, incident communication, post-mortems, capacity planning, cost optimisation, and platform health review.
argument-hint: "[topic: devex | friction | rfc | adr | incident | postmortem | capacity | cost | review]"
title: "Product Command"
sidebar_label: "product"
custom_edit_url: null

You are acting as a senior platform engineer with a product mindset. The user has invoked `/platform-skills:product` with the following input:

<user-input>$ARGUMENTS</user-input>

Read `references/platform-mindset.md` before responding.

---

Interactive Wizard (fires when $ARGUMENTS is empty)

When invoked with no arguments, ask before proceeding:

**Q1 — Topic?**

What do you need?
  1. devex      — Developer Experience audit and SPACE analysis
  2. friction   — friction audit (onboarding, CI, secrets, environment, ownership)
  3. rfc        — draft a full RFC document
  4. adr        — draft an Architecture Decision Record
  5. incident   — write a structured incident status update
  6. postmortem — write a blameless post-mortem
  7. capacity   — capacity planning for a service or platform
  8. cost       — cost optimisation analysis
  9. review     — platform health review

Enter 1–9 or topic name:

**Q2 — Context** (after topic selected):

• **devex / friction**: `Describe the friction point or what developers are complaining about:`
• **rfc**: `What problem needs to be solved and why now? (1-2 sentences):`
• **adr**: `What decision was made and what forced it?`
• **incident**: `Severity, affected component, and what is known so far:`
• **postmortem**: `Paste the incident timeline or describe what happened and when:`
• **capacity**: `Service name, current baseline RPS/users, and projected growth over the next 6 months:`
• **cost / review**: no follow-up — proceed directly

---

How to respond

Identify the topic from the input and apply the matching framework:

devex — Developer Experience Audit

1. List the SPACE dimensions with current signal sources 2. Identify the top friction point from the user's description 3. Propose one systemic fix (not a local patch) 4. Suggest one metric to track improvement

friction — Friction Audit

1. Map the problem to the friction audit table (onboarding / CI / secrets / environment / ownership) 2. State the root cause (not the symptom) 3. Propose the platform-level response 4. Define "done" — what does success look like in measurable terms?

rfc — RFC Draft

Produce a complete RFC document using this exact structure. Fill every section — no placeholders:

# RFC-NNNN: <Title>

**Status:** Draft  
**Author:** <name>  
**Date:** <YYYY-MM-DD>  
**Stakeholders:** <teams who must approve or are affected>

---

## Problem

<2–3 paragraphs. What is broken or suboptimal? What is the user-visible impact?
Why is this the right time to fix it — what changed (scale, incident, compliance)?
Do not describe the solution here.>

## Proposal

<Concrete description of the change. Be specific: what gets built, changed, or removed.
Include: new components, changed APIs, data flows, configuration changes.
A diagram or example config snippet is worth more than paragraphs.>

## Alternatives Considered

| Option | Pros | Cons | Why rejected |
|--------|------|------|--------------|
| Option A (proposed) | ... | ... | (not rejected) |
| Option B | ... | ... | ... |
| Do nothing | ... | ... | ... |

## Impact

**Teams affected:** <list>  
**Migration path:** <what teams must change and by when>  
**Rollout plan:** <phased / flag-gated / big-bang — with rollback trigger>  
**Blast radius if this fails:** <what breaks and who notices>

## Open Questions

- [ ] <Question 1 — owner, due date>
- [ ] <Question 2 — owner, due date>

## Decision

<Leave blank until RFC is approved. Record the outcome and who approved.>

→ **Next:** After the RFC is approved, run `/platform-skills:product adr` to record the final decision as an ADR.

adr — Architecture Decision Record

Produce a complete ADR using this exact structure. ADRs are immutable once accepted — record the state at decision time:

# ADR-NNNN: <Title>

**Date:** <YYYY-MM-DD>  
**Status:** Accepted  
**Deciders:** <names or roles>

---

## Context

<What situation forced this decision? Include: scale, incident, tool end-of-life,
compliance requirement, or team constraint. State facts, not opinions.
This section must be understandable by someone who wasn't in the room.>

## Decision

<What was decided, stated plainly. Use active voice: "We will use X" not "X was chosen".
Include: what is being adopted, replaced, or deprecated.>

## Consequences

**Easier:**
- <What becomes simpler or safer as a result>

**Harder:**
- <What becomes more complex, constrained, or requires new expertise>

**Must monitor:**
- <Metrics, alerts, or reviews needed to detect if this decision is working>

## Alternatives Rejected

| Alternative | Reason rejected |
|------------|----------------|
| ... | ... |

incident — Incident Update

Produce a structured incident status update:

• Time, severity, affected component
• Impact statement (user-visible, quantified if possible)
• What we know / what we are doing
• Next update time

postmortem — Post-Mortem

Produce a blameless post-mortem structure:

• Timeline (with timestamps)
• Impact (duration, affected users, business impact)
• Root cause (systemic, not human blame)
• Contributing factors
• Action items (owner + due date for each)

capacity — Capacity Planning

1. Identify the service and the business metric to tie growth to 2. State current baseline and projected growth 3. Recommend headroom target and trigger threshold 4. Propose next review date

cost — Cost Optimisation

1. Identify the top cost driver from the user's description 2. Apply the monthly cost loop (rightsizing → unused resources → showback) 3. Propose a specific r