consult-publish

name	consult-publish
description	This skill should be used when a consultant elects to turn a completed cogni-consult deliverable into presentation-ready documentation — a brief the consultant hands to Claude Design to render. Trigger on: "publish this deliverable", "turn <deliverable> into slides", "make a poster/web page from <deliverable>", "build a report from <deliverable>", "make an infographic from <deliverable>", "present this deliverable", "render-ready brief", or "hand this to Claude Design". Runs only when the named deliverable's `state` is `complete`. It is consultant-elected: invoke it explicitly — it is never auto-fired from the design-thinking loop.
allowed-tools	Read, Write, Edit, Bash, Skill

Publish a Deliverable

Turn one completed deliverable into a brief — the clean handoff the consultant takes to Claude Design (claude.ai/design) to render in their own design system. This skill produces the brief and records its path; it never renders and never owns brand. Rendering and brand application live in Claude Design, by design.

The routing — which format becomes which brief, built by which route — is the canonical contract in $CLAUDE_PLUGIN_ROOT/references/publish-routing.md. This skill executes that contract rather than restating it, so the routing cannot drift between the reference and the skill. Read the reference before building any brief; the per-format detail below is an execution summary, not a second source of truth.

When this runs

Publishing is a consultant judgment call — which deliverables are presentation-worthy, and which format fits each. So this skill is elected, not automatic:

• It runs only when the consultant invokes it explicitly on a named deliverable.
• It runs only when that deliverable's state is complete in its field's field.json (a deliverable still in its design-thinking loop is not ready to present).
• It is never wired into the consult-design-thinking empathize→test loop as a post-test callback. The loop ends at state: complete; publishing is a separate, later, deliberate step.

Workflow

1. Locate the engagement and the deliverable

Resolve the engagement root (the directory holding consult-project.json) and read the named action field's action-fields/<field-slug>/field.json. Find the deliverable entry by its slug.

Gate on completeness. If the deliverable's state is not complete, stop and tell the consultant the deliverable must finish its design-thinking loop (and ideally its persona challenge) before it can be published — name the current state and dt_stage. Do not publish an unfinished deliverable.

The deliverable artifact is at action-fields/<field-slug>/<deliverable-slug>.md. Read it — its framework structure is what the brief is built from.

2. Elect the format

The four target formats are slides, web-poster, report, and infographic. The choice is the consultant's and is not fixed per deliverable type. The deliverable artifact's frontmatter may record a format preference (deliverable-types.md records it at production time); read it and offer it as the default, but let the consultant confirm or override. A deliverable may be published to more than one format — each published format appends its own lineage entry (step 5), so a second format never overwrites the first.

3. Optional voice polish

The brief text may be polished with cogni-copywriting:copywriter before handoff. This is optional and graceful-degrading — if cogni-copywriting is not installed, skip it with a one-line note; the route still produces a valid brief.

All four formats now build their brief in step 4, so the polish target is the same across the board: polish the drafted brief after step 4 builds it (there is no separate brief text until then). Polishing the deliverable itself is unnecessary — no route post-processes it through an external renderer on the standard path.

The dispatch invocation and the --scope options (tone / compress / full) are the canonical ones in $CLAUDE_PLUGIN_ROOT/references/publish-routing.md — see its "Optional Voice Polish" section rather than restating them here. One hard rule regardless of scope: the polish must preserve {{asm:id}} placeholder tokens verbatim — a reworded token no longer matches the step-4.5 resolver and would slip past the fail-loud gate.

4. Build the brief by route

Resolve the elected format to its route per publish-routing.md — the reference holds the exact dispatch block and per-route options; the mapping below is the execution summary, so read the reference for each route before dispatching:

Elected format	Route	Brief output path
slides / web-poster	consult-native outline brief (built here, not dispatched)	action-fields/<field-slug>/publish/<deliverable-slug>-outline.md
report	consult-native report-outline brief (built here, not dispatched)	action-fields/<field-slug>/publish/<deliverable-slug>-report-outline.md
infographic	consult-native infographic brief (built here, not dispatched)	action-fields/<field-slug>/publish/<deliverable-slug>-infographic-brief.md

Building the consult-native outline (slides / web-poster). This is the one route the skill builds itself rather than dispatching. Consult deliverables are framework-shaped (Pyramid / SCQA / MECE), not arc-shaped, so this path does not dispatch cogni-visual:story-to-slides / story-to-web and does not re-narrate through cogni-narrative — arc-ifying a framework-shaped deliverable weakens its executive register. Derive the outline directly from the deliverable's own structure: an ordered list of {section_title, section_body} entries with citations preserved — Pyramid answer / governing thought → the opening, each MECE group / SCQA movement → one section in the deliverable's own order, supporting evidence carried into the matching section body (never dropped). The plain title-and-description outline is exactly what Claude Design's presentation generator consumes.

The author may additionally layer the optional presentation-intent annotation on this outline — a design: front-matter block, a per-slide slide_points/talk_track split, a per-slide type: tag, brief-level key_figures:, and climax/TBD marks — so the deck builds in one renderer pass instead of a clarify-then-build round. It is optional and additive: a brief without it still renders. Build it per the Optional presentation-intent layer subsection in publish-routing.md (the canonical schema) — do not restate the field shape here.

The report and infographic routes are built here too, not dispatched — derive a consult-native brief directly from the deliverable's framework (a report-outline brief, or an infographic brief of headline + hero facts + MECE segments + takeaway), citations preserved. publish-routing.md holds the per-route brief recipe and output path — follow it rather than restating them here, so the skill and the reference cannot drift.

No render dependency. All four routes build a brief natively and never render, so the run never requires cogni-visual. cogni-visual:enrich-report / story-to-infographic remain available only as an explicit opt-in local-render fallback (they render locally and apply a cogni-visual theme, which the brief-only contract otherwise avoids) — they are no longer the standard path. When cogni-copywriting is absent, the optional polish step is skipped. Either way the run still produces a valid brief.

4.5 Resolve assumption placeholders (mandatory)

After the brief is written — and after any optional step-3 polish, so resolution is unambiguously the last transformation before step 5 — resolve every {{asm:id}} placeholder against the engagement's assumptions.json registry (the single source of truth for assumption values — schema in $CLAUDE_PLUGIN_ROOT/references/data-model.md). Unlike the step-3 polish, this pass is mandatory and fail-loud, not optional and graceful-degrading: a placeholder that cannot be resolved must stop the publish, never ship as a literal {{asm:...}} in a client-facing brief and never be silently dropped.

Run the resolver on the built brief in place; the exact invocation and failure contract are canonical in $CLAUDE_PLUGIN_ROOT/references/publish-routing.md (Assumption Resolution section) — read it rather than restating it here. On success: false, stop the publish, tell the consultant which assumption ids are unknown (the envelope lists all of them), and do not proceed to step 5 — the engagement's registry (or the deliverable's placeholder) needs fixing first. A brief with no placeholders passes trivially.

5. Record the publish lineage in field.json

Store the brief as a path reference plus lineage on the deliverable entry — never copy brief content into consult state. Mirroring the source-lineage contract, the deliverable and its downstream brief are linked by path, so an upstream correction stays visible downstream without duplication.

Add (append) one entry to the deliverable's publish array in action-fields/<field-slug>/field.json via a direct Edit — the field.json seam needs no script (engagement-status.sh passes every deliverable field through verbatim). Shape:

"publish": [
  {
    "format": "slides",
    "brief_path": "action-fields/<field-slug>/publish/<deliverable-slug>-outline.md",
    "route_steps": ["consult-native-outline", "copywriter:tone"],
    "source_deliverable": "<deliverable-slug>",
    "published_at": "<ISO-8601 timestamp>"
  }
]

brief_path is the route's output path — the outline for slides/web-poster, the <deliverable-slug>-report-outline.md for report, or the <deliverable-slug>-infographic-brief.md for infographic (all under publish/). route_steps records the build chain actually run, named for the native builder: consult-native-outline (slides/web-poster), consult-native-report-outline (report), or consult-native-infographic-brief (infographic), plus any copywriter:<scope> polish (or a skipped polish, noted as such). Because publish is an array, publishing a second format appends a new entry rather than overwriting the first.

6. Print the Claude Design handoff

End by pointing the consultant at the handoff: the brief's path is the handoff. Print the brief path and the one-line instruction — hand the brief to Claude Design (claude.ai/design) to render it in your design system. cogni-consult stops at the brief; Claude Design renders and applies brand.

If multiple formats were produced in this session, list each brief path.

Important Notes

• Elected, never automatic. This skill runs only on explicit consultant invocation against a complete deliverable. It must never be auto-fired from the consult-design-thinking loop or any other skill's close step — those may point to it, but the consultant elects it.
• Path reference, not content copy. The brief is stored as a brief_path in field.json; brief content is never duplicated into consult state. The link is the path, so corrections cascade without drift.
• The plugin's responsibility ends at the brief. Rendering and brand application happen in Claude Design. This skill produces no rendered artifact and owns no theme.
• No render dependency. Every format builds a consult-native brief, so the standard path never requires cogni-visual — it remains an opt-in local-render fallback only. When cogni-copywriting is absent the optional polish step is skipped. Either way the run still produces a valid brief — a missing downstream plugin degrades the output, it never fails the run.
• Assumption resolution is fail-loud, not graceful-degrading. The step-4.5 {{asm:id}} pass is the one mandatory gate between building a brief and handing it off — a missing polish degrades style, but an unresolved assumption ships a wrong or placeholder number to a client.
• Framework-shaped, not arc-shaped. All four routes build the brief directly from the deliverable's framework (Pyramid/MECE/SCQA). None arc-ifies and none dispatches the arc-optimized cogni-visual story skills on the standard path — that is a deliberate quality choice, not an omission.