Customer-Facing Product Specification

Produce an external narrative product specification for customers and partners. The reader is outside the company (a customer evaluating the product, or a partner integrating with it). They need to understand what the product does, how it behaves, and how to work with it — never how it is built internally.

Two non-negotiable principles govern everything below:

1. Describe behavior, not implementation. State observable product behavior, user-facing contracts, and partner requirements. Never state internal architecture, infrastructure, source systems, vendors, or algorithms.
2. Strict allow-list redaction. Only information that is explicitly customer/partner-relevant is included. Anything that even resembles a proprietary internal detail is excluded by default and surfaced to the user as a question — not silently published. See reference/redaction-rules.md.

Workflow

1. Gather inputs (interview, don't assume)

Ask the user for: the product/feature name, the target audience (which customers/partners), the spec's purpose (evaluation, integration, contractual reference), and any source material (internal docs, PRDs, code). If source material contains internal detail, that's expected — your job is to translate the external-relevant parts and drop the rest.

Ask 3–6 focused questions if scope is unclear. Do not pad with assumptions.

2. Draft against the template

Use reference/spec-template.md as the structure. Fill only sections that apply; omit sections that don't rather than inventing content. Write in clear, plain prose aimed at a technical-but-external reader. Prefer concrete, verifiable statements over marketing language.

3. Apply the redaction rules continuously

While drafting, run every candidate statement through the allow-list test in reference/redaction-rules.md. When you encounter information that is useful but proprietary, do not include a sanitized guess — instead leave a [REDACTED — confirm external-safe phrasing with user] marker and list it for review in step 4.

4. Mandatory pre-publish leak-check (do not skip)

Before presenting the finished spec, perform an explicit second pass dedicated solely to leakage. Read reference/redaction-rules.md and check the draft line by line against the forbidden-category checklist there. Produce a short Leak-Check Report for the user containing:

• ✅ Categories confirmed clean.
• ⚠️ Every borderline statement, quoted verbatim, with the category it risks and a proposed external-safe rewrite.
• ❓ Every [REDACTED …] marker that needs a user decision.

Never present a spec as final until the Leak-Check Report has been shown and the ⚠️/❓ items resolved with the user.

5. Editorial pass (after leak-check only)

Once the Leak-Check Report's ⚠️/❓ items are resolved, apply the writing-clearly-and-concisely skill to tighten grammar, structure, and clarity. This pass runs after redaction, never before. It must not rewrite, paraphrase, or "improve" any [REDACTED …] marker or reintroduce excluded detail — if a sentence can't be improved without touching redacted content, leave it as-is and note it.

6. Deliver

Output the spec as Markdown. If the user wants it published, suggest the official notion, atlassian (Confluence), or mintlify integrations — do not push it anywhere without explicit confirmation.

Hard rules

• When unsure whether something is external-safe, treat it as proprietary and ask. Default to exclusion.
• Never substitute a real internal vendor/tool/system name with a plausible-but-invented one; redact and flag instead.
• Do not infer or speculate about roadmap, pricing internals, or unreleased capabilities.