Corporate Press Release

Inputs from client-data

• companies/{client_slug}/brand_context.json — resolved brand; read expression (principles, signatureElements, antiPatterns) for compact brand direction and identity.positioning. Reference, never bind — prose guidance, not hard rules.
• companies/{client_slug}/company_context.json — redacted public company facts (company.*: name, description, HQ, services, positioning) and public spokesperson metadata (people[]: name, title, publicRole, publicBio, quoteStyle)
• companies/{client_slug}/press-releases/ (optional) — prior press releases / content library (spokespersons, boilerplate, distribution-lists, approval-matrix)
• companies/{client_slug}/boilerplate.json (optional) — company-wide boilerplate, including contact_block (signer + firm + contact lines, locale-keyed: default_en/default_nl) and sign_off (closing salutation) used for the Media Contact block and any signed cover note
• companies/{client_slug}/voice/voice-profile.md (optional) — entity voice profile (L2)
• companies/{client_slug}/voice/voice-anchors.md (optional) — entity voice anchors (L2)

Voice

A press release is prose, so run the org voice cascade before drafting the
headline, lede, body, and quotes.

1. Read the L1 baseline. When the stromy-format MCP is connected, read
   voice://baseline (anti-AI-smell rules) and voice://review (the pre-output
   review checklist) via ReadMcpResourceTool.
2. Read the local L2 profile when present. Resolve the company slug as in
   "Company Data Integration" and read
   companies/<slug>/voice/voice-profile.md and voice-anchors.md
   if they exist. When no slug is in scope, use the local stromy profile only
   if that directory exists; otherwise proceed with L1 only.
3. Two-pass write. Draft the release, run the review checklist against it,
   then rewrite once before sending it into the approval workflow. Quotes are
   the usual offender for AI cadence; check them especially.

This is a text-only voice pass. The skill mentions the cascade as context; it
does not invoke another skill.

Research

A press release lives or dies on its facts, so run the org research cascade
before and during Fact Pack Assembly (Phase 2) — gather facts before drafting,
never improvise them into the release.

1. Read the L1 discipline. When the stromy-format MCP is connected, read
   research://baseline, research://capability-map, and
   research://fact-discipline via ReadMcpResourceTool.
2. Pick a path via the capability map (attended vs unattended). Use WebSearch
   (if enabled) or nl-gov-data for official-source facts; billed research-apify
   runs only on an explicit/confirmed request. If that is the only available path
   and it wasn't confirmed, ask first.
3. Apply fact-discipline to every claim. Cite-or-hedge; state the precise
   stage of any legislative/regulatory claim (announced / introduced / passed /
   in-force) and never imply a later one; flag forward-looking claims; record
   provenance; surface gaps — never fabricate a figure, date, quote, or
   citation. A press release that overstates is a correction waiting to happen.
4. If no research path is available, say so and do not fabricate — ask the
   user to supply the facts, or draft only from what is confirmed (flagging the
   unverified). At the governance-review / approval step, present the
   claims-with-sources and the unverified / forward-looking flags alongside the
   draft.

The discipline is read from its canonical home at run time, not embedded here.
The skill mentions the cascade as context; it does not invoke another skill.

Deliverable canvas (prerequisite)

This skill produces a multi-section deliverable. Collaborate through a single
chat artifact — the deliverable canvas. The canvas is the source of truth for
the in-progress draft; chat scroll-back is not.

1. Resolve the section plan from this skill's own workflow. Use the
   approved structure this skill already defines (or the prompt/resource it
   names). The canvas protocol does not invent sections.
2. Choose the substrate. Use markdown by default for strategic wording,
   plans, and other content where layout does not change meaning. Use html
   only when visual arrangement materially affects the user's decision. HTML is
   a one-way display surface only: never call back into an MCP from the
   artifact.
3. Open the canvas. Mint an 8-character hex canvas_id, then emit exactly
   one artifact with identifier canvas-<canvas_id>-<deliverable_type>. One
   chat = one canvas.
4. Iterate in the canvas. After every change, re-emit the full canvas
   as a new version of the same artifact. Never emit deltas. Never mint a
   second canvas mid-session.
5. Self-check before handoff. Every planned section exists, is substantive,
   and appears in the agreed order. No TBD, placeholders, or pending
   structural questions remain.
6. Sign-off gate. Ask the user to confirm the canvas is final before any
   render handoff or client-data write.
7. Construct the envelope. Hand off {deliverable_type, title, client_id, sections:[{id, title, body}], meta:{canvas_id, substrate, methodology_version}}, where methodology_version is 1. The downstream
   formatter or terminal write step consumes the envelope — never raw chat
   history.

Overview

This skill produces corporate press releases that are simultaneously newsworthy, journalist-friendly, factually rigorous, digitally discoverable, and legally reviewed for disclosure risk. It owns the full lifecycle — from deciding whether an announcement merits a release through drafting, approval, distribution planning, and post-publication corrections.

Press releases are still valued by journalists (Cision reports 72% prefer receiving them from PR teams), but relevance is the biggest filter. This skill enforces a newsworthiness gate before any drafting begins.

Company Data Integration

No overlay — STOP. If companies/ has no entry for this client, do NOT fabricate company details, invent spokesperson names, or default to a Stromy brand. State: "No company overlay found — client data unavailable. Please ensure the plugin is deployed with the correct companies/<slug>/ overlay." Do not continue to draft.

Discovery

1. Resolve {client_slug} from the invoking plugin's companies/ directory:
   • Zero entries → STOP (see guard above).
   • One entry → use it directly; state the resolved client name at the start of your response (e.g. "Using the brand.").
   • Multiple entries → ask the user which company is announcing; do not guess.
2. If the overlay exists but the announced company isn't in it → gather company details manually and note the gap.

Loading Company Data

companies/{client_slug}/company_context.json   → Public company facts + spokesperson metadata:
  company.name / displayName                   → Legal and display name for boilerplate / attribution
  company.description                          → "About <Company>" boilerplate
  company.headquarters.city / country          → Dateline city and country
  company.publicContact.website / press        → Public website and press contact URL (no personal email/phone)
  people[]                                     → Public spokespeople: name, title, publicRole, publicBio, quoteStyle

companies/{client_slug}/brand_context.json     → Resolved brand: expression, colors, fonts, logo (for branded PDF/HTML versions)
companies/{client_slug}/press-releases/        → Press release content library (all optional):
  ├── spokespersons.json     → Approved spokespersons with titles, quote style, topics (overrides people[])
  ├── boilerplate.json       → Company boilerplate versions (standard, short, product-specific)
  ├── distribution-lists.json → Media lists by beat, region, tier
  └── approval-matrix.json   → Sign-off requirements by announcement classification

When no press-releases/ sub-directory exists, use company_context.json for identity and spokesperson data, and ask the user for boilerplate variants and approval requirements.

PII note: company_context.json contains only public-role data. Spokesperson personal contact details (personal email, phone) are intentionally redacted. Use only name, title, publicRole, publicBio, and quoteStyle from people[]. For the media contact block, use company.publicContact.press (a URL or generic press address) or ask the user for a specific media contact.

Content Assembly

Release Section	Content Source	Fallback
Dateline city	company_context.company.headquarters.city	Ask user
Boilerplate	press-releases/boilerplate.json → match by variant; else company_context.company.description	Ask user for 2-3 sentence company description
Spokesperson	press-releases/spokespersons.json → match by topic; else company_context.people[] filtered by publicRole	Ask user for name, title, quote
Media contact	boilerplate.json → contact_block (locale-matched variant, emit verbatim); else press-releases/spokespersons.json → mediaContact role; else company_context.company.publicContact.press	Ask user for a direct press contact
Closing salutation (signed cover note only)	boilerplate.json → sign_off (locale/register-matched variant)	Omit — AP-style releases need no salutation
Approval chain	press-releases/approval-matrix.json → match by classification	Default: Comms lead + subject-matter owner
Distribution	press-releases/distribution-lists.json → match by beat	Recommend wire + targeted list

Workflow

The workflow has 8 phases. Phases 1-4 happen before any writing. This is intentional — the most common corporate press release mistakes happen before drafting, not during it.

Phase 1 — Intake & Classification

Step 1: Receive the announcement
User provides the news — could be a brief, bullet points, internal memo, or verbal description.

Step 2: Classify the announcement

Classification	Characteristics	Governance Level
Ordinary	Product update, event, hire, partnership	Standard (Comms + owner)
Reputationally sensitive	Layoffs, legal settlement, controversy response	Elevated (Comms + Legal + Exec)
Market-sensitive	Earnings, M&A, material contracts, forecasts	Full (Comms + Legal + IR + Board)
Crisis	Safety issue, data breach, regulatory action	Immediate (Crisis team + Legal + Exec)

Present the classification to the user for confirmation. The classification determines which governance steps are mandatory.

Step 3: Newsworthiness gate

Before drafting, apply the "So what?" test. The announcement should pass at least 2 of these criteria:

• Timeliness — Is this happening now or very soon?
• Impact — Does this affect customers, markets, or communities?
• Novelty — Is this a first, an industry change, or genuinely new?
• Prominence — Are notable people, companies, or brands involved?
• Relevance — Does this connect to a current trend or public concern?

If the announcement fails the gate, recommend alternatives: blog post, internal memo, social media post, or newsletter item. Explain why — don't just reject it.

Step 4: Is this actually a press release?

Some announcements are better served by a different format:

If the news is...	Consider instead
Routine internal update	Internal memo or intranet post
Thought leadership / opinion	Blog post or bylined article
Regulatory filing	Regulatory submission (not PR-first)
Brief factual statement	Media statement (not full release)
Product detail for existing users	Product changelog or email

Phase 2 — Fact Pack Assembly

Gather and classify every claim that will appear in the release.

Source hierarchy (highest trust first):

1. Company-approved facts — Board-approved numbers, official stats, verified milestones
2. Public verifiable facts — Published financials, regulatory filings, industry reports
3. Estimates/projections — Internal forecasts, market sizing (require "forward-looking" disclaimer)
4. Third-party claims — Analyst quotes, partner statements (require attribution and permission)

For each key claim, record: the fact, its source, who approved it, and when it was last verified.

Risk screen — Flag any of these for legal review:

• Forward-looking statements or financial projections
• Customer names (need permission to reference)
• Competitive claims ("first," "only," "leading," "best")
• Regulated language (healthcare, financial services, defense)
• Inside information (for listed companies)
• Personal data or privacy-sensitive details

Phase 3 — Governance Review

Load the appropriate review path from press-releases/approval-matrix.json based on classification, or use these defaults:

Classification	Required Sign-offs	Before Drafting	Before Distribution
Ordinary	Comms lead, subject-matter owner	Fact pack	Final draft
Reputationally sensitive	+ Legal counsel, executive sponsor	Fact pack + messaging	Final draft + quotes
Market-sensitive	+ IR/compliance, disclosure counsel	Fact pack + materiality assessment	Final draft + timing + wire selection
Crisis	+ Crisis team lead, CEO/delegate	Holding statement first	Every version

For listed companies: Coordinate timing with market hours. Material information must be disclosed broadly and simultaneously — not selectively to favored journalists. See governance-workflow.md for SEC Reg FD and FCA guidance.

Present the approval requirements to the user. The draft comes next, but the user should know who needs to sign off before writing begins.

Phase 4 — Release Blueprint

Before drafting, present a structural outline for confirmation. It's much cheaper to adjust the angle or swap a quote strategy now than to rewrite a finished release — especially for reputationally sensitive or market-sensitive announcements where every word gets scrutinized.

Present to the user:

1. News angle — The core story in one sentence. What makes this newsworthy? (This becomes the lead.)
2. Headline direction — 2-3 candidate headlines showing the framing (not final copy — just direction)
3. Fact selection — Which facts from the fact pack will carry the story. What's in, what's background, what's cut.
4. Quote strategy — Who speaks, about what theme. If two quotes, what each one covers and why. (Match spokesperson to topic using spokespersons.json or user input.)
5. Boilerplate variant — Which version (standard, short, product-specific) fits this release
6. Concerns — Missing facts, weak angles, governance flags, or anything that could stall the draft

Skip the blueprint when:

• The user has already provided a near-complete draft for refinement
• The release is a straightforward ordinary announcement with no governance complexity

For all other cases — especially reputationally sensitive and market-sensitive releases — the blueprint saves revision cycles and prevents the common failure of drafting first, then discovering the angle doesn't hold up under legal review.

Wait for confirmation or adjustments before proceeding to Phase 5.

Phase 5 — Draft the Release

Now write. Follow AP-style conventions and inverted pyramid structure.

Brand expression (read before drafting) — reference, never bind. Before writing, read expression from brand_context.json. If present, use as prose guidance:

• expression.principles — inform the rhetorical register (e.g., "measured authority" → factual lede, no hype; "evidence before decoration" → data-led subheads)
• expression.signatureElements — reflect where appropriate in structural choices (e.g., a brand with an "editorial" type expression may use a tighter, sharper headline)
• expression.antiPatterns — treat as a ban-list alongside the voice cascade's forbidden constructions
• identity.positioning — use to calibrate the "why this matters" framing in supporting paragraphs
• If expression is absent, fall back to the voice profile only with a soft note; no hard failure
• Voice-cascade rule: expression is additive to the L1 baseline + L2 profile bans, never a relaxation. Expression principles may sharpen tone but must not reintroduce a banned construction. Where a Brand Context API narrative is attached (candidate.context), treat it as input evidence for expression principles, not a voice source that overrides the cascade.

Structure (every release, in this order):

1. Headline — The news in plain language, 6-12 words, under 100 characters
2. Subheadline (optional) — Supporting context or key metric
3. Dateline — CITY, Month Day, Year —
4. Lead paragraph — Who, what, when, where, why in 25-30 words
5. Supporting paragraph(s) — Context, evidence, business significance
6. Quote — Executive perspective, not fact repetition (1-2 quotes max)
7. Additional detail — Features, availability, timeline, next steps
8. Boilerplate — Company description (from content library or profile)
9. Media contact — Name, title, email, direct phone
10. ### — Standard end marker

Length target: 300-500 words. Shorter is better. If the release exceeds 500 words, cut — every sentence should either communicate the news, prove it, explain why it matters, or enable follow-up.

For detailed editorial rules (headline formulas, quote patterns, AP style reference, what to avoid), see editorial-standards.md.

For type-specific guidance (what to emphasize for product launches vs. funding vs. crisis), see announcement-types.md.

Phase 6 — Review & Validation

Editorial checklist:

• Headline states the news plainly (no hype, no jargon)
• Lead answers the 5 Ws in under 35 words
• Inverted pyramid maintained (most important first)
• All claims traced to fact pack with approved sources
• Quotes add perspective, not enthusiasm
• No unsupported superlatives ("world-leading," "game-changing")
• AP-style conventions followed (dateline, numbers, titles)
• Boilerplate current and accurate
• Media contact has direct details (not a switchboard)
• Word count 300-500

Governance checklist (based on classification):

• All required sign-offs identified and communicated
• Forward-looking statements flagged with appropriate disclaimer
• Customer/partner names cleared for use
• Competitive claims substantiated
• Market-sensitive timing coordinated with IR (if applicable)
• Embargo terms documented (if applicable)

Fact-verification gate (non-skippable close-out — research://verification-gate).
The "All claims traced to fact pack" checkbox above is not a self-report — enforce
it mechanically before the release is marked ready (read the L1 resource when the
connector is present:
ReadMcpResourceTool(server="stromy-format", uri="research://verification-gate")):

• (a) Recompute every derived number in the release (a percentage, ratio, growth
  figure, or delta) from its stated inputs and flag any mismatch.
• (b) Resolve every citation and third-party claim (analyst quote, study, market
  figure) to a real, findable source via the capability-map path (attended:
  WebSearch / nl-gov-data / confirmed research-apify / attended browser;
  unattended: WebSearch → STOP-and-surface if no free path exists). A real citation
  with an unreachable primary softens + flags "unverified against primary"; contested
  figures across sources soften to a directional statement + flag — neither hard-blocks.
• (c) Trace every non-obvious claim to the fact pack or a source (cite-or-hedge);
  flag unsourced assertions.
• Blocking rule: an unresolved citation or an unreconciled arithmetic
  mismatch means the release is NOT marked ready — fix the claim (replace/soften)
  or ask; never ship on a self-report. Fold the digest
  ({claims, unresolved_citations, recomputed_mismatches}) into the pre-publish
  digest this skill already presents (Research §).

Phase 7 — Distribution Planning

Recommend a distribution approach based on announcement type and classification. See distribution-guide.md for the full decision tree.

Quick reference:

Classification	Primary Channel	Supporting
Ordinary	Targeted outreach by beat	Company newsroom, social
Reputationally sensitive	Targeted outreach + newsroom	Social only if positive framing
Market-sensitive	Regulatory wire (RNS/DGAP) first, then broad wire	Newsroom after wire clears
Crisis	Direct to affected parties, then wire	Newsroom, social, stakeholder email

Multimedia: Include when it materially helps the story — product images, data visualizations, executive headshots, video. 20% of reporters are more likely to pursue a story with multimedia attached.

SEO: Include relevant keywords in headline and first paragraph. Link to landing page or newsroom. But the story must read like news first — discoverability is secondary to accuracy.

Phase 8 — Post-Publication

After the release goes out:

1. Monitor pickup — Track media coverage, social shares, journalist inquiries
2. Correct promptly — If errors are discovered, issue a correction and update the newsroom version. PRSA ethics standards require prompt correction of inaccuracies.
3. Archive — Save the final version with metadata (date, classification, distribution channel, pickup summary)
4. Debrief — For major announcements, note what worked and what didn't for future releases

Reference Files

Load these as needed — do not read all at once.

File	When to Load
editorial-standards.md	When drafting (Phase 5). AP style, headline rules, quote patterns, length guidance, common mistakes.
governance-workflow.md	When handling market-sensitive or crisis announcements (Phases 1-3). Materiality screening, SEC/FCA guidance, approval matrices, correction procedures.
distribution-guide.md	When planning distribution (Phase 7). Wire vs. targeted, SEO, multimedia, embargo protocol, timing by market rules, localization.
announcement-types.md	When drafting type-specific content (Phase 5). Detailed guidance per announcement type with examples.

Output Format

The primary output is a markdown-formatted press release. After the content is finalized, produce the document in the user's requested format.

Markdown Template

# [HEADLINE IN TITLE CASE]

## [Subheadline — optional]

**[CITY, Month Day, Year]** — [Lead paragraph: the complete story in 25-30 words.]

[Supporting paragraph with context, evidence, and significance.]

"[Executive quote — perspective, not facts]," said [Full Name], [Title] at [Company].

[Additional detail: features, availability, timeline.]

"[Optional second quote from partner/customer/analyst]," said [Full Name], [Title] at [Organization].

[Closing: call to action, where to learn more.]

### About [Company Name]

[2-3 sentence boilerplate from content library or company_context.company.description]

### Media Contact

[Name]
[Title], [Company]
[Email] | [Phone]

###

When companies/{client_slug}/boilerplate.json carries a contact_block, emit the locale-matched
variant verbatim in the Media Contact block instead of the [Name]/[Title]/… placeholders
(it already holds the signer, firm, and contact lines). Resolve the locale/register-keyed map to
the chosen variant's value — never emit the raw JSON or a key name. If a signed cover note
accompanies the release, close it with the sign_off variant. Absence is not failure: a client
whose boilerplate.json lacks these fields (or has none) falls back to the table's other sources;
never fabricate a contact or salutation.

Output Format Production

Gate: do not produce formatted output until the deliverable canvas sign-off gate has passed (see "Deliverable canvas" above).

This skill owns press release content — structure, editorial quality, governance, and distribution planning. Render-path document production goes through format-prepare-document, which then routes to the terminal renderer.

Output	Routed renderer	What it provides
DOCX	format-docx	Word document creation with branded letterhead styling, headers/footers
PDF	format-pdf-hd	PDF creation for distribution-ready releases

Default: If the user doesn't specify a format, produce markdown first and ask whether they'd like a formatted DOCX or PDF. Press releases are most commonly distributed as PDF attachments or pasted into wire services — recommend accordingly.

Brand context to carry forward when producing formatted output through format-prepare-document:

• Brand location: companies/{client_slug}/brand_context.json
• Apply heading color from colors.primary, body font from typography.body, logo from logos/ (path in brand_context.logo)
• Use the document section from brand_context.json for margins, headers, footers
• Include company logo on the release header if available
• Include resolved expression (if present) and deliverable_genre: "press-release" in the envelope for downstream render direction

After the release is delivered, mention (never auto-activate) that the user can capture feedback with asset-feedback, and file your own source: agent retrospective there if the run hit an instruction gap or tool-call failure worth fixing.

Output Location

Press releases follow the Workspace Studio project structure on the operator's local disk:

workspace/<client>/
├── build/<deliverable>/    ← build scripts and intermediates
└── output/<deliverable>/   ← final press release files (docx, pdf)

In the Claude app (plugin use) there is no local workspace/ tree. Hand the
finished content to the format skill, which delivers it into the client's
SharePoint space using the folder tree declared in
companies/<slug>/workspace.json. Never create a folder named after this
structure (workspace/, <client>/, output/) in SharePoint; the tree there
is the client's setting, not this skill's.

Override: If the prompt specifies a target output directory, pass it through to the output format skill.

Error Handling

Situation	Response
Announcement fails newsworthiness gate	Recommend alternative format, explain why
No company data available	Gather essentials manually, note missing fields
Classification unclear	Present options with reasoning, let user decide
Quote not provided	Draft a template quote, ask for review/approval
Missing media contact	Flag as blocker — every release needs a real contact
Legal review flagged but not available	Draft with risk flags visible, note that legal must review before distribution
Exceeds 500 words	Cut ruthlessly — highlight what can be moved to a fact sheet