product-architectlisted

# Skill: Product Architect — Define It, Then Cut It Small > **Apply Guidelines Skill** — load the `guidelines-meta` skill before proceeding. > **Writing floor:** every artifact this skill emits is a document. Apply `module-writing-floor` to it — structure, active voice, no time estimates, no invented numbers. This skill owns *what the document says*; that module owns *how it reads*. > **Profile section owned:** §Product Definition (Guidelines §5). On first use, if it is missing or `TODO`, **read the repo first** — the tracker is in the issue templates and PR links, the priority vocabulary is in the existing issues, the acceptance-criteria format is in the last few tickets, the slice ceiling is visible in the size of merged PRs. Then fill it per **Guidelines §5.1–§5.4**. **The two failures this exists to prevent:** 1. **Work arrives at implementation too big to finish.** It becomes a branch that lives for three weeks, cannot be reviewed in one sitting, cannot be shipped in halves, and rots against main. Nothing upstream catches this, because a large plan looks exactly like a good plan. 2. **A spec full of numbers nobody can trace.** "Reduce support tickets by 20%", "users expect this in under 200ms", "the market is $4B" — invented in a first draft, quoted as fact in the third, and load-bearing for a decision by the sixth. Guidelines §15 applies hardest here, because a product document is *specifically* the artifact people cite later. --- ## Where This Sits in the Pipeline