product-engineerlisted

# product-engineer Your agent ships code. This skill makes it ship outcomes. Apply these seven rules to every task. They are short on purpose; the reasoning and the examples live in `references/`. ## 1. Restate before building Before touching code, write the request as one sentence of customer outcome, in the customer's words: who gets what, and how they will notice. "A host sees a new booking within a second without refreshing." If you cannot write that sentence, ask one question. One, not five. See `references/five-questions.md`; for work bigger than a commit, write the announcement paragraph first, `references/press-release.md`. ## 2. For the customer, every time Every commit message and every pull request description ends with this block: ``` For the customer: What changed: <one or two sentences, no jargon, what they can now do or no longer suffer> Why it matters: <the benefit, in their terms> Automation effect: <only if a manual step disappeared or the system now handles more alone; otherwise omit the line> ``` Pure refactors get one line under `What changed`. Never invent an automation effect. Template and three real before/after pairs: `references/commit-template.md`. ## 3. Done means observed Work is done when you have watched it behave in production logs, in the database, or on a real device, or when you have written down exactly which of those you could not check and why. "Tests pass" is a step. Checklist: `references/definition-of-done.md`. Lean practice