junhao-presentation-style

name

junhao-presentation-style

description

Use when creating, redesigning, or QA-reviewing PowerPoint/PPTX decks for Junhao Zhang that should carry the Aiforce-style research dossier visual language from junhao-frontend-style: warm paper background, editorial Chinese serif headings, carbon briefing boards, red/teal/ochre/green/cobalt semantic accents, numbered section plates, matrix tables, SOP timelines, architecture diagrams, and PM-facing research readability. Trigger for requests such as PPT, slides, deck, presentation, 转成PPT, 做一个风格一致的PPT, Aiforce PPT风格, 俊豪PPT风格, or migrating the Junhao frontend dossier style into presentation work.

Junhao Presentation Style

Operating Rule

Use this skill as the style and layout system for PPT work. When an actual .pptx must be created, edited, rendered, or verified, also use the Presentations skill and follow its artifact-tool presentation JSX workflow.

Do not convert the HTML style literally. Translate it into a slide-native system: fewer objects per page, stronger claim titles, larger proof objects, and a contact sheet that still reads as one warm research dossier.

Style Target

Create a warm research dossier deck:

• Internal research memo, PM decision deck, or technical strategy briefing.
• Editorial and rigorous, not SaaS-template, consulting-blue, neon AI, or decorative gradient.
• High-density but legible. Every slide should have a claim, a proof object, and one clear next-read area.
• Mostly light paper panels. Use dark carbon panels only for covers, briefing boards, chapter dividers, template headers, or high-value summary rails.

Slide Design Tokens

Use these colors unless the user provides a stronger brand system:

paper        #f4efe2
paper-deep   #e7dcc5
panel        #fffaf0
ink          #25231f
ink-2        #4d463c
muted        #746b5d
carbon       #191814
line         rgba(37,35,31,0.18)
red          #b43d2f   core risk / decision / thesis
teal         #147070   workflow / output / deliverable
ochre        #b9781e   tradeoff / attention
green        #52743d   validation / completion
cobalt       #2d5f88   technical path / references
soft-red     #fae4db
soft-teal    #dcefed
soft-ochre   #f4e5c7
soft-green   #e5edd8
soft-cobalt  #dce8ef

Use installed fonts only. Prefer:

• Body and labels: IBM Plex Sans, PingFang SC, Microsoft YaHei, sans.
• H1/H2/section claims: Noto Serif SC, Songti SC, STSong, serif.
• Fallback is acceptable, but the title/body contrast must remain visible.

Default slide size: 1280x720 widescreen.

Deck Structure

For Junhao's business or technical research decks, default to this arc:

1. Cover / one-sentence conclusion.
2. Problem framing and why now.
3. System state, lifecycle, or architecture map.
4. Method or option comparison matrix.
5. SOP / execution timeline.
6. Evaluation metrics and decision gates.
7. Risks, assumptions, and mitigation.
8. Next actions / ownership checklist.

Keep wording decision-oriented. Avoid marketing filler and empty section introductions.

Slide Layout Families

Use at least four of these families in a normal 6-10 slide deck. Avoid three consecutive slides with the same macro layout.

Cover With Briefing Board

Translate the HTML hero into one integrated cover surface:

• Warm paper background with subtle grid texture.
• Left: eyebrow pill, large serif claim title, short lead paragraph, north-star callout with a red left rule.
• Right: compact carbon briefing board with 2x2 metric cells and a metadata list.
• Metric cells use top accent rules: red, teal, ochre, green.
• Do not split the cover into unrelated cards.

Chapter Divider

Use a strong numbered plate instead of a generic title slide:

• 68-84 px square number plate, paper fill, carbon border, hard carbon offset shadow.
• Large serif chapter claim.
• One sentence that says what decision this chapter supports.
• Optional carbon strip for chapter metadata.

Evidence Slide

Use one dominant proof object:

• Chart, architecture map, comparison table, timeline, or decision gate grid.
• Direct labels preferred over legends.
• Quiet footer with source/date if evidence is external.
• No decorative containers around prose.

Matrix Table

Translate HTML .matrix tables into slide-native matrices:

• Carbon header row with warm text.
• First column bold and slightly darker.
• Thin ink lines, compact row height, and semantic accent chips.
• Use table only when comparison is the proof object; otherwise use cards or a diagram.

SOP Timeline

Translate .sprint-list into a horizontal or vertical execution rail:

• Fixed step markers, carbon border, red tabular numerals.
• Each step has: action, decision/checkpoint, deliverable.
• Use teal deliverable strips.
• Keep markers aligned to one rail; avoid scattered "Step 1" labels.

Architecture / Flow

Use precise geometry:

• Stages or modules are equal-role boxes with consistent padding.
• Connectors attach cleanly and encode real direction or dependency.
• Red marks risk/decision points, teal marks outputs, cobalt marks technical systems, green marks validation.
• Avoid icon stacks unless icons clarify a real operation.

Decision Gates

Use 3-5 gate cards only when each card encodes a different decision:

• 7 px top accent border.
• Short gate name, pass/fail signal, evidence required, output decision.
• Do not use generic rounded cards as default scaffolding.

Component Rules

Use small radii: 0-8 px. Prefer square, dossier-like panels.

Use background texture sparingly:

• Paper fill plus fine grid lines.
• Optional rotated grid panel on cover or divider.
• No decorative orbs, bokeh blobs, neon gradients, or purple AI backgrounds.

Use semantic accents consistently:

• Red: thesis, risk, core judgment.
• Teal: workflow, output, deliverable.
• Ochre: tradeoff, uncertainty, watch item.
• Green: validation, completion, positive gate.
• Cobalt: technical path, reference, system layer.

Use dark panels rarely:

• Cover briefing board.
• Chapter metadata strip.
• Template/table header.
• Final recommendation board.

If a slide becomes mostly dark, it should be an intentional divider or summary, not the default deck look.

Typography And Density

For 1280x720 slides:

• Cover title: 54-72 px, serif, line-height 1.05-1.14.
• Section/chapter claim: 44-64 px, serif.
• Normal slide claim title: 32-44 px, preferably conclusion-first.
• Body text: 17-23 px.
• Table and chart labels: 11-15 px, never below 10 px for core reading.
• Footers and source notes: 8-10 px only when non-core.

Use claim titles, not topic titles.

Bad: Method Comparison

Good: UCPO-Ask is the shortest path from preference optimization to agent behavior control.

PPT Build Workflow

When producing a real deck:

1. Read or infer the audience, purpose, and source content.
2. Generate the outline before filling slides. The outline must include the deck thesis, section order, slide-by-slide claim titles, proof objects, and expected deliverable for each slide.
3. Do not start detailed slide filling until the outline is coherent. If the user is available and the deck is strategic or high-stakes, show the outline for confirmation before building the full PPT.
4. Route through the Presentations skill task mode and profile.
5. Convert the approved or self-checked outline into a claim spine before designing slides.
6. Lock this design system in the deck's design-system.txt.
7. Plan the contact sheet with varied layout families.
8. Build editable slides with artifact-tool presentation JSX.
9. Render previews and inspect the contact sheet.
10. Fix weak slides before exporting the final .pptx.

Outline first, fill second. Do not treat a slide deck as a sequence of styled content dumps; the structure must carry the argument before visual execution.

If the user only asks to migrate or define the style, update/create the skill without fabricating a content deck.

QA Checklist

Before delivery, verify:

• Contact sheet looks like one authored warm dossier deck.
• Cover has integrated hero/briefing-board logic, not two unrelated cards.
• At least four macro layout families appear in a 6-10 slide deck.
• Titles state conclusions.
• Every non-divider slide has one dominant proof object.
• Matrix headers are carbon, not beige-only.
• Number plates and step markers feel strong enough at thumbnail size.
• Red/teal/ochre/green/cobalt usage is semantic, not decorative.
• Dark panels are rare and information-bearing.
• Text does not collide with panel edges, rules, markers, or connectors.
• All charts, tables, flows, and connectors still read correctly after render.
• No fabricated logos, pseudo-brand marks, or unverifiable product UI.

Failure Modes

Fix these before calling the deck done:

• Generic consulting or SaaS theme replaces the paper dossier feel.
• Beige palette becomes one-note without carbon or semantic accents.
• Repeated card grids dominate the deck.
• Cover lacks a real briefing board information model.
• Slides preserve content but lose decision hierarchy.
• Tables are squeezed until unreadable.
• Timeline steps lack deliverables.
• Architecture boxes say generic labels without relationships.
• Decorative marks become louder than the evidence.