Artifact Style and Template Guidelines

Purpose

Define a reviewable style brief and select the right authorized template before another builder creates or refreshes a PPTX, DOCX, XLSX, HTML microsite, engagement hub, external customer site, report, playbook, runbook, or diagram. This skill normally guides a specialist builder; it does not create substantive content by itself.

Use style to improve hierarchy, comprehension, consistency, and accessibility. Styling never changes the audience authorization of content. Never make internal or private material customer-safe merely by changing its appearance.

Authorship and use

Author: Bill Whalen with Microsoft Scout.

License: MIT.

Audience lanes

Choose exactly one primary lane and name any secondary review audience.

Do not move content between lanes without a separate content review. Redaction, approval, sensitivity, access, and publication controls remain mandatory even when the visual treatment is correct.

Intake

Before recommending a style or template, capture:

• Artifact type and exact output format, dimensions, orientation, or viewport.
• Primary audience lane, readers, decision context, and expected reading time.
• Purpose, desired action, narrative, and success criteria.
• Approved brand, brand owner, and any usage restrictions.
• Existing official template, canonical example, layout library, or asset pack.
• Accessibility requirements, including contrast, keyboard use, alt text, and reading order.
• Delivery medium: live presentation, print, email attachment, shared workspace, offline package, or browser.
• MIP label or other sensitivity classification; never infer or downgrade it.
• Coauthoring state, authoritative destination, file owner, and whether the source is read-only.
• Source provenance, as-of date, freshness expectations, and citation requirements.
• Required components, length, localization, print/save behavior, and known technical constraints.

If essential facts are missing, mark them as open questions. Do not invent brand rules, permissions, freshness, citations, or audience approval.

Template-first selection

1. Inventory official or canonical templates and brand assets already available from authorized sources. Record name, owner, version or date, intended audience, supported format, layouts/components, fonts, asset rights, and source location without copying private content into the brief.
2. Confirm that the selected template is approved for the artifact, audience, delivery medium, and brand. Prefer the newest authoritative version unless an owner directs otherwise.
3. Reuse the exact template, theme, masters, layouts, styles, components, and approved assets. Do not mimic a template from screenshots or rebuild an approximation when the canonical source is available.
4. Do not scrape, download, trace, or copy third-party brands, templates, logos, fonts, imagery, or examples without explicit permission and usage rights.
5. If no authorized template exists, use the Microsoft-neutral fallback below and label it as a fallback rather than an official brand system.
6. Preserve coauthored and canonical originals. Create a new file or governed copy, retain source provenance, and route it for review. Never overwrite an original or destructively edit it without explicit approval.

Selection priority: audience authorization, official status, format fit, accessibility, delivery-medium fit, freshness, then visual preference. Record rejected candidates and the reason when the choice is not obvious.

Microsoft-neutral fallback tokens

Use these only when no approved template or brand system applies. Adjust for medium and accessibility, and document every material exception.

Visual system

• Dominance: establish one unmistakable focal point per page, slide, view, sheet, or diagram. Supporting elements must remain visibly subordinate.
• Motif: choose one quiet motif tied to the subject, such as a grid, framing device, restrained shape family, or data-led visual rhythm. Repeat it consistently; do not add decoration without meaning.
• Whitespace: use deliberate negative space and clear grouping. Increase space between sections before adding rules, boxes, or ornament.
• Color: start with accessible neutral surfaces and text, then add a small semantic or content-aligned accent palette. Verify contrast. Do not hardcode a generic blue-only "AI" aesthetic or use gradients, glow, glass effects, or futuristic decoration by default.
• Typography: prefer Aptos for body text and Aptos Display for display text when available. Use no more than three purposeful size tiers in a local composition. Keep body text comfortably readable for its medium; as starting points, use at least 18 pt for presentation body text, 10.5-12 pt for office documents and worksheets, and 16 CSS px for web body text. Increase sizes for distance, density, or accessibility needs.
• Alignment: align to an explicit grid, maintain consistent margins and gutters, and use optical alignment for icons and chart labels. Avoid nearly aligned edges.
• Hierarchy: prefer meaningful headings, labeled sections, callouts, tables, charts, and short statements over unstructured text. Do not use title underline accent lines. Do not use raw bullet dumps or emoji headings unless requested; when bullets are appropriate, make them parallel, concise, and intentionally styled.
• Imagery and icons: use only authorized, relevant assets with sufficient resolution, consistent treatment, and alt text where supported. Never use an icon as the sole carrier of meaning.

Artifact-specific guidance

PPTX

• State the visual intent and audience takeaway for every slide before layout.
• Build a narrative arc and vary approved layouts; do not repeat one title-and- bullets composition across the deck.
• Use the template's masters and layouts, native editable shapes, and native charts where practical. Keep chart encodings and legends consistent.
• Put delivery guidance, source detail, and optional talk track in speaker notes without hiding required audience content there.
• Add citations close to claims and visuals, with a readable source treatment.
• Render every slide, inspect at presentation scale and thumbnail scale, fix overflow, clipping, collisions, weak contrast, tiny text, chart legibility, and visual monotony, then render again.

DOCX

• Use real paragraph, character, list, caption, and table styles rather than manual formatting.
• Maintain a valid heading hierarchy and generate a TOC when the document's length or navigation needs justify one.
• Use accessible tables with header rows, sensible column widths, and no layout tables when semantic structure is expected.
• Apply intentional headers, footers, page numbers, section breaks, and page breaks. Prevent orphan headings and accidental blank pages.
• Add alt text to meaningful visuals and mark decorative elements appropriately when the format supports it.

XLSX

• Use structured tables for tabular data, stable headers, filters where useful, and frozen panes that preserve row and column context.
• Apply readable, locale-aware number, date, currency, percentage, and unit formats. Distinguish inputs, formulas, outputs, and assumptions without relying on color alone.
• Use conditional formatting sparingly and semantically; define thresholds and avoid decorative heatmaps.
• Prefer native charts linked to source ranges. Label axes, units, time periods, and exceptions.
• Preserve formulas unless replacement is approved. Recalculate with a compatible engine, inspect formula results, and deliver with no #REF!, #DIV/0!, #VALUE!, #NAME?, or other visible errors.

HTML and microsites

• Prefer a self-contained, sandbox-safe package that remains useful offline.
• Make layouts responsive across phone, tablet, desktop, zoom, and reduced viewport widths. Avoid horizontal scrolling for primary content.
• Support keyboard navigation, visible focus, semantic landmarks, logical heading order, sufficient contrast, alt text, and reduced-motion preferences.
• Do not add external dependencies, remote fonts, analytics, telemetry, trackers, forms, embeds, or network calls unless each is explicitly approved.
• Provide usable print and save behavior, including print styles when the artifact is expected to become a PDF or hard copy.

Engagement hubs and sites

• Internal working cockpits may use higher information density, persistent navigation, status indicators, ownership, provenance, and evidence links, but must remain scannable and sensitivity-aware.
• Internal executive/business views should lead with decisions, outcomes, tradeoffs, risks, and next actions rather than operational detail.
• Customer-facing sites must be built only from separately reviewed customer-safe inputs and must omit internal notes, private metadata, hidden fields, draft commentary, and unapproved links.
• Shared V-Team core artifacts should be modular, reusable, neutrally branded, provenance-bearing, and free of account-specific private content.

Reports, playbooks, runbooks, and diagrams

• Reports should expose scope, as-of date, sources, method, findings, limitations, decisions, and actions in a predictable hierarchy.
• Playbooks and runbooks should separate purpose, prerequisites, roles, procedures, decision points, rollback or escalation, evidence, and completion criteria.
• Diagrams should use consistent notation, directional flow, labeled boundaries, a legend when needed, and readable text at the intended viewing size. Do not imply architecture, data flow, or controls that sources do not support.

Standard output

Return a compact handoff with these sections:

1. Style brief: artifact, audience lane, purpose, tone, desired action, delivery medium, accessibility, sensitivity, and source freshness.
2. Template inventory and selection: authorized candidates, selected exact template/layouts, provenance/version, rationale, and rejected candidates.
3. Design tokens: typography, color roles and contrast, spacing, grid, motif, imagery, iconography, chart and table conventions.
4. Component and layout rules: reusable patterns, density, hierarchy, responsive or print behavior, and prohibited patterns.
5. Redaction and audience boundary: allowed content, excluded content, unresolved approvals, and any required content review.
6. Artifact-specific QA checklist: checks tailored to the selected format.
7. Exceptions: deviations, owner, reason, impact, and review needed.
8. Receipt: source/template identifiers, output-as-new-file expectation, decisions, checks completed, fixes made, remaining concerns, reviewer, and as-of date. Keep private source bodies and raw data out of the receipt.

Unless the user explicitly asks this skill to build, stop at the handoff and pass it to the appropriate builder. Never treat the handoff as permission to publish, share, send, upload, or overwrite.

Relationship to builder skills

• pptx, docx, and xlsx implement Office artifacts.
• web-artifacts-builder implements self-contained web artifacts and may carry a mandatory host theme/token system. That mandatory theme takes precedence over this skill's neutral fallback tokens unless the builder contract itself authorizes an override.
• create-engagement-hub governs engagement workspace assembly.
• create-external-customer-site governs customer-safe packaging and external publication gates.
• webinar-factory and industry-workshop-factory govern their specialized narratives and production workflows.

This skill supplies style and template decisions to those builders. It cannot weaken or override their technical validation, content review, identity, privacy, access, publication, or delivery gates. When another skill has stricter requirements, follow the stricter requirement.

QA and fix loop

Check the final artifact, not only its source representation:

• Content hierarchy, narrative flow, and lane-appropriate density.
• Contrast, color independence, reading order, keyboard use, alt text, and other applicable accessibility requirements.
• Overflow, clipping, collisions, truncation, alignment, grids, margins, gutters, pagination, and whitespace.
• Citation presence, claim-to-source mapping, source freshness, and readable provenance.
• Unresolved placeholders, comments, hidden content, notes, stale samples, and accidental internal metadata.
• Broken links, missing assets, unsupported dependencies, and offline behavior.
• Mobile, zoom, responsive, print, and save behavior where applicable.
• Office open/repair warnings, native object integrity, formula recalculation, and format-specific validation.

For every visual artifact, perform at least one full inspect, fix, and verify cycle after the first render or open. Record what changed and the evidence from the final verification. If the required renderer or application is unavailable, state the limitation and do not claim visual QA passed.

Hard boundaries

• No template or brand-asset download from an unapproved source.
• No third-party brand imitation or asset reuse without permission.
• No MIP or sensitivity downgrade, relabeling, or bypass.
• No sharing, publishing, sending, uploading, permission grants, or recipient changes under this skill.
• No raw private data in style briefs, examples, logs, receipts, or outputs.
• No unsupported claims, invented citations, fabricated freshness, or implied approval.
• No credentials, secrets, tokens, private endpoints, or telemetry insertion.
• No overwrite, destructive edit, or mutation of a canonical or coauthored original without explicit approval.
• No assumption that visual polish changes authorization, confidentiality, or audience eligibility.

Author: Bill Whalen with Microsoft Scout. License: MIT.