Phoenix Design Skills
Designer guide · v8.6

International SOS design team

Design with confidence.

Four focused Figma Skills to standardize screens, check optional Jira brief coverage, create context-aware states, add realistic content, prepare work for engineering, and turn comments into an actionable task list—with two private tools for Phoenix maintainers.

Before you start

Four steps. One persistent result.

Every Skill creates or refreshes a report beside your selection, so the outcome stays with the design—not inside a transient chat.

SelectChoose the relevant frame, screen, or screens in Figma.
CallOpen Figma AI and type / followed by the Skill name.
DirectAdd an optional instruction to control focus, mode, or output.
ReviewUse the persistent report and its linked layer references.

Release notes · v8.6

What changed, and why.

v8.6 keeps the four-skill architecture, optional Jira alignment, dark readable reports, and private maintainer tools, while preserving meaningful designer-authored layer names.

Phoenix-specific

From Phoenix Core and team testing

  • DSM first: the Phoenix-Core Design System 2.0 parent library is checked before its dependent libraries.
  • Jira brief alignment: an explicit Jira key/link or pasted brief can be checked against the selected design; without a readable brief, the report says Brief alignment: Not assessed instead of guessing product requirements.
  • Spacing safeguards: valid 2px and 10px Auto Layout tokens are recognized; Auto/Space-between and intentional zero gaps are preserved.
  • Protected intent: approved component internals, badges and risk/status labels, and verified global map widgets stay untouched.
  • Traceable reports: visible layer paths use verified Figma NODE hyperlinks to supported containing frames or instances.
  • Readable artifacts: generated report sections recalculate height bottom-up so content is not clipped.
  • Reliable text wrapping: body copy fills the available width and uses Auto height; headings and section frames Hug their content after every node is appended.
  • Dark report system: persistent reports use a #232B3B canvas, high-contrast light text, and blue styling only for API-verified node links.
  • Naming preservation: meaningful existing names such as wrapper, content, container, section, and stack remain unchanged. Only obvious numbered Figma defaults are eligible for automatic renaming.
  • Generated naming: one concept uses one lowercase singular word; multiword generated names use kebab-case, such as country-guide. Components, variants, properties, and published contracts require confirmation and are never renamed automatically.
  • Team conventions: generated copy uses American English.
  • Professional craft gate: creation starts with a task, visual anchor, hierarchy, composition, and approved reference—not a collection of generic UI parts. The gate translates proven front-end craft and anti-slop preflight practices into Figma-native behavior.
  • Quality stop: generic card mosaics, filler copy, decorative chrome, lookalike components, and unverified token claims must be repaired before completion.
  • Relationship-first spacing: the spacing-audit pattern compares hierarchy and proximity at equivalent levels, accepts Phoenix 2px/10px tokens, and ignores Auto/Space-between and intentional zero gaps.
  • Explicit flow connections: the connect-screens pattern is used only when the designer asks and the source/target are unambiguous; existing interactions are preserved.
  • Bounded interface quality: the better-interface pattern informs evidence-backed hierarchy, layout, typography, content, and component checks instead of a generic redesign.
Community-informed

Patterns adopted for v8.3

  • Inspect before infer: discover variables, styles, components, variants, and modes before declaring anything missing.
  • State Intelligence: create only contextually relevant loading, empty, no-results, validation, success, and error states.
  • Selection-aware behavior: adapt the review to a component, screen, set of screens, or end-to-end flow.
  • Clear findings: use Blocker, Action, Consider, and Passed instead of arbitrary scores.
  • Action sequence: inspect → act → validate → document → summarize.
  • Verified comments: read full threads, deduplicate genuine duplicates, and verify completion against the current canvas.
  • UX writing consistency: the figma-ux-writing-style pattern informs role-aware, concise American English without blanket rewriting of protected product language.
  • Conservative cleanup: the layer-cleanup pattern reports the smallest useful path and never deletes content without an explicit request.
  • Scoped notes: spec-notes and annotate-redlines inform optional, concise notes limited to non-obvious responsive, spacing, truncation, and token decisions.
  • Maintainer patterns: create-anatomy, create-property, and create-color inform anatomy, property contracts, color mapping, and documentation readiness in the two private Skills rather than the public workflow.
How community input was used: we adopted useful interaction and reporting patterns, not the individual Community Skills. Phoenix Core, International SOS conventions, and the safeguards learned through our own Figma testing remain the source of truth.
Jira brief alignment: call /phoenix-design with a Jira key/link or attached brief to create a requirement-to-design traceability section. If no readable brief is supplied, the report states Brief alignment: Not assessed. Existing slash commands remain unchanged; the clearer display title for handoff is Phoenix Handoff Check, and comments are shown as Phoenix Comment Tasks.
v8.6 report and naming contract: every public and private canvas artifact uses a fixed-width, Hug-height root; Fill-width, Hug-height sections; Fill-width, Auto-height body copy; and Hug headings. Reports use #232B3B with primary #F7F9FC, secondary #C7D0DD, muted #AAB6C6, verified links #8CABFA, and link hover/focus #B8CCFF. Text is styled and sized before textAutoResize is enabled, and frame-only height stabilization runs bottom-up. Existing meaningful layer names are preserved; only obvious numbered Figma defaults may be renamed automatically. The palette is a generated-report exception—not a Phoenix product-interface token recommendation.

01 · Standardize

Phoenix Design

phoenix-design

Improve, compare, or review selected screens, components, and flows using Phoenix Core.

What it does
  • Inspects the DSM first, then checks tokens, typography, fixed spacing, radius, effects, components, and Auto Layout.
  • Compares equivalent elements across selected screens and adapts to components, screens, or flows.
  • Runs a relationship-first spacing audit and maps raw dimensional values to the nearest verified Phoenix token when safe, including valid 2px and 10px gaps.
  • Uses State Intelligence to create relevant loading, empty, no-results, validation, success, and error states when requested.
  • Can create, extend, or recompose screens only from verified Phoenix assets—never lookalike components—and applies a professional craft gate plus bounded interface-quality pass.
  • Checks an explicitly supplied Jira brief or acceptance criteria against visible design evidence without inventing requirements.
  • Creates prototype connections only when explicitly requested and source/target intent is unambiguous.
  • Applies high-confidence fixes directly and reports decisions using Blocker, Action, Consider, and Passed.

Preserves Auto/Space-between gaps, zero-value defaults, badges, risk/status content, approved component internals, and verified map widgets.

Modes
  • Improve: apply safe Phoenix fixes to a single screen or component.
  • Compare / Baseline: match equivalent elements across selected screens and flag or synchronize deterministic differences.
  • Spacing Audit: compare hierarchy, proximity, and rhythm; ignore Auto/Space-between and zero gaps.
  • Brief Check: map an explicit Jira brief to selected screens, components, or flows; default is read-only.
  • States: create only workflow-supported loading, empty, error, success, or no-results states.
  • Create / Variant / Recompose: build from verified Phoenix assets and pass the professional craft gate.
  • Review only: inspect and document without changing the design.
Canvas output
Phoenix Design Report — [Selection]

Improve, compare, state, and Brief Check work always creates or refreshes a linked report—even with zero findings. A Brief Check includes the Jira source (or Brief alignment: Not assessed), a requirement matrix, linked evidence, and next actions. Reports use the v8.6 dark report, verified wrapping, and naming-preservation contract. Create, extend, and recompose requests keep the generated screen as the primary output and create a report only when requested or when unresolved safety findings need documenting.

Try asking

02 · Populate

Phoenix Content

phoenix-content

Replace placeholder content with believable enterprise data and controlled edge cases.

What it does
  • Replaces eligible names, addresses, dates, currencies, metrics, tables, and operational copy.
  • Uses American English while preserving authentic international data.
  • Applies a bounded, role-aware UX-writing pass when requested, without blanket rewriting.
  • Can validate explicit Jira content, locale, data, or state requirements when a brief is supplied; without one, brief alignment is not assessed.
  • Supports Apply, Preview, and Stress test modes.
  • Checks clipping and wrapping after replacement without changing spacing by default.

Never rewrites structural labels, legal or meaningful production copy, badges, risk/status content, approved component internals, or verified maps.

Time format
  • Operational: 2026-07-22 14:30 UTC
  • Spacious: 6 minutes ago · 2 hours ago · 1 day ago
  • Dense: 6m ago · 2h ago · 1d ago
Modes & safeguards
  • Apply: replace eligible demo values directly and report the result.
  • Stress test: add controlled long, short, international, dense, unavailable, and edge-case data.
  • Preview: show proposed replacements without editing.
  • Classifies text by role before acting; skips ambiguous or meaningful production copy.
  • Never rewrites badges, risk/severity/status labels, approved component internals, or verified map widgets.
Canvas output
Phoenix Content Report — [Selection]

Changed layers, representative before/after examples, skipped content, stress cases, layout issues, optional Jira content coverage, and verified links to containing frames. The dark report uses Fill-width, Auto-height text so long before/after examples wrap without clipping.

Try asking

03 · Prepare

Phoenix Handoff

phoenix-handoff

A designer-focused readiness check before work moves to engineering.

What it checks
  • Obvious numbered Figma-default names, hidden/default/empty-layer hygiene, file structure, and inspectability. Existing meaningful names such as wrapper, content, container, section, and stack are preserved.
  • Phoenix tokens, text styles, components, variants, and safe overrides.
  • Auto Layout, resizing, clipping, overflow, and essential screen states.
  • Relevant form clarity, table readiness, and semantic color context.
  • Optional Jira brief coverage when an explicit issue or brief is supplied; otherwise it marks brief alignment as not assessed.
  • Optional concise spec notes or redlines for non-obvious exceptions.
  • Optional selection-aware component, screen, or flow documentation only when explicitly requested.

It trusts Phoenix Core and Storybook. Prepare mode stays designer-focused; it does not add developer specifications, tab order, ARIA documentation, analytics, effort estimates, or numbered overlays unless the designer explicitly asks for Document, Annotate, or Full handoff.

Review scope
  • Prepare: check only what the selection supports—layers, tokens, components, layout, content, forms, tables, and semantic color context.
  • Document: create the smallest useful selection-aware handoff page only when requested.
  • Annotate: duplicate the source and add a restrained set of linked callouts only when requested.
  • Approved Phoenix internals, Storybook-defined states, touch-target measurements, full contrast audits, and detailed ARIA/tab-order notes remain out of the default check.
Canvas output
Phoenix Handoff Check — [Selection]

Ready, Ready with fixes, or Not ready, with compact Blocker/Action/Consider/Passed checks and linked layer paths. The dark, high-contrast frame Hugs all sections and validates every body text node before completion. When supplied, the report also includes Jira brief coverage. Document and Annotate outputs are optional.

Try asking

04 · Organize

Comments to Tasks

phoenix-comments-to-tasks

Turn page comments into a structured task list without touching the source threads.

What it does
  • Reads full accessible comment threads, replies, and resolution state on the current page.
  • Separates actionable work, clarification items, general feedback, and resolved or obsolete threads.
  • Verifies completion against the current design, deduplicates only genuinely identical requests, and preserves source references.
  • Retains any supplied Jira key or link as task provenance without treating it as proof that comments are duplicates or requirements are met.
  • Preserves authorship and links each task to its affected location.

It does not modify designs, reply to comments, resolve threads, or update Jira. Requests affecting protected Phoenix internals are routed to clarification.

Task grouping
  • Action: a concrete change that can be worked through.
  • Clarification: a decision or confirmation needed from the designer.
  • Discussion: useful context that is not a task.
  • Resolved / obsolete: retained as an excluded count when it no longer applies.
  • Replies are folded into the parent thread; genuine duplicates are grouped, while distinct requests stay separate.
Canvas output
Phoenix Comment Tasks — [Page]

Prioritized tasks grouped by screen, clarification and verification items, excluded discussion counts, and verified links to affected containers. Long comment context wraps inside Fill-width, Auto-height text on the shared dark report surface.

Try asking

Recommended workflow

From brief to confident handoff.

Use the four Skills in sequence—or call the one that matches the work in front of you. Add a Jira brief to the Design, Content, or Handoff request when traceability matters. Every action is validated and documented on the canvas.

01

Standardize

/phoenix-design
Improve the design and create requested states using verified Phoenix assets.

02

Populate

/phoenix-content
Replace placeholders and expose content-driven layout issues.

03

Prepare

/phoenix-handoff
Confirm the work is clean and ready for engineering.

04

Organize

/phoenix-comments-to-tasks
Turn review feedback into verified, deduplicated tasks.

Built-in safeguards

Automation with clear boundaries.

The Skills act on safe, verifiable changes and keep ambiguous decisions visible.

Phoenix is the source of truth

Variables, styles, components, modes, and valid 2px/10px spacing tokens are checked in the file before judgment.

Protected content stays protected

Badges, risk/status labels, verified maps, and approved component internals are not rewritten or audited internally.

Meaningful names stay intact

Existing names such as wrapper, content, container, section, and stack are preserved. Only obvious numbered Figma defaults may be renamed automatically, and component contracts always require confirmation.

Reports remain readable

Generated artifacts use a dark high-contrast theme, Auto-height wrapping text, Hug-height sections, and bottom-up frame recalculation to prevent overlap and clipping.

Links must actually work

Text findings target a supported containing frame or instance and are styled as links only after API verification.

Findings stay actionable

Reports use Blocker, Action, Consider, and Passed instead of invented scores, with a clear action → validate → document → summarize sequence.

Useful custom instructions

Say what you need in plain language.

Add one of these after invoking a Skill. Select any example to copy it.

05–06 · Design system maintenance

Document and keep the library healthy.

These two private Skills are for Phoenix design system managers. They work in a separate documentation file, keep the DSM authoritative, and create persistent reference or hygiene artifacts without expanding the public designer workflow.

05 · Private maintainer Skill

Phoenix Documentation

/phoenix-documentation

Document one selected main component, component set, variant, or child instance in Phoenix Core Design System — Documentation. The Skill inspects the published DSM source before writing, then creates or refreshes one compact component page.

  • Reference shape: identity, purpose, live preview, anatomy, variants and properties, supported states, token/style mapping, content guidance, accessibility notes, related components, gotchas, and change history.
  • Evidence rule: exact property names, values, modes, bindings, and source links are recorded only when verified. Missing evidence is marked Undocumented, not invented.
  • Optional detail: anatomy callouts, color specifications, and concise spec notes can be requested when they add useful reference value.
  • Canvas output: Phoenix Component Documentation — [Component], using the shared dark report system, real node links, and verified Auto-height text.

Boundary: never edit the evolving DSM source, rename properties, recolor approved internals, or create a lookalike component.

06 · Private maintainer Skill

Phoenix Component Hygiene

/phoenix-component-hygiene

Run a read-only health check on a Phoenix component or component set before publishing, documenting, or releasing changes. The Skill checks the library contract and maintainability—not the visual quality of a product screen.

  • Contract: component identity, set membership, variant matrix, property types/values/defaults/order, instance links, and published status.
  • Bindings: variables, styles, modes, color mapping, typography, radius, effects, fixed spacing, and Auto Layout behavior.
  • Hygiene: default names, hidden or empty layers, stale wrappers, redundant nesting, descriptions, documentation links, and documentation readiness.
  • Canvas output: Phoenix Component Hygiene — [Selection] with the shared dark report system, verified wrapping, and linked Blocker, Action, Consider, and Passed findings.

Boundary: published contracts, component internals, badges, risk/status labels, verified map widgets, Auto/Space-between gaps, and intentional zero values remain protected.

Recommended setup: keep the documentation file separate from DSM / Phoenix-Core Design System 2.0 (WIP). Use Skill 5 as the structured component reference and Skill 6 as the health gate; both can later feed a Storybook-like web reference without becoming a second source of truth.