LinkedIn Animated Infographics

View saved version →

---
name: exact-svg-mascot
description: Animate a named or official mascot using the exact user-supplied SVG while preserving its identity. Use when the mascot asset must not be redrawn, substituted, approximated, or silently regenerated.
---

# Exact SVG Mascot

## Purpose

Animate the exact SVG supplied by the user without changing the mascot's identity.

This is an asset-integrity workflow. The supplied SVG is the identity source.

## Blocking asset gate

Before animation:

1. confirm an SVG file was supplied or is directly available to the task
2. confirm the file is actually SVG content and can be read
3. preserve an untouched source copy or source representation for comparison
4. inspect `viewBox`, visible groups/elements, transforms, clipping, and IDs/classes that may support animation

If the exact SVG is missing, unreadable, or not actually SVG, return `HOLD` and request the exact asset.

Do not:

- redraw the mascot
- generate a lookalike
- substitute another mascot
- trace a raster image into a replacement
- replace the identity with emoji, iconography, or a generic character

## Motion directions

Develop 2-3 motion directions around geometry that already exists in the SVG. Examples include:

- whole-character entrance or travel
- head/body/limb motion when the SVG structure safely supports it
- eye or expression changes only when the original SVG contains appropriate elements
- prop movement when the prop is part of the supplied SVG
- reading-pointer movement that guides attention through the infographic

Do not invent new facial features, body parts, logos, or branded details.

## Implementation rules

Prefer non-destructive animation:

- CSS transforms on existing SVG groups
- SVG transforms on existing elements
- opacity changes on existing elements
- clip or mask animation only when existing identity remains intact
- wrapper movement around the untouched SVG when internal rigging is unsafe

Avoid rewriting path geometry unless the user explicitly asks for a morph and identity preservation can be verified.

The final animated composition must keep the original mascot recognizable at every important frame.

## Identity check

Before delivery compare the animated mascot with the original source for:

- silhouette
- proportions
- colors
- logo/brand markings
- face and defining features
- accessory placement

Any unintended identity drift is blocking.

## Output

Return:

- asset validation verdict
- selected motion direction
- which original SVG elements are animated
- identity-preservation notes
- final artifact or integration instructions
- final verdict: `PASS`, `FAIL:fixable`, or `HOLD`

Never complete a named-mascot request by substituting an asset when the exact SVG gate fails.

View saved version →

---
name: host-workspace-operator
description: Inspect, search, modify, and verify files or repository state using the safest host-native ChatGPT/Codex capabilities available.
---

# Host Workspace Operator

Use workspace capabilities supplied by the current ChatGPT/Codex host. This Skill does not grant filesystem access and must never invent a tool that the host did not expose.

## Capability order

Prefer the narrowest operation that can complete the job:

1. `read` for a known file or exact range
2. `list` when the workspace shape is unknown
3. `search` for broad or semantic discovery
4. `grep` for exact text, symbols, fields, or regex patterns
5. `patch` for a focused existing-file edit
6. `write` only when the requested workflow authorizes mutation
7. `shell` for repository commands when narrower file tools are insufficient
8. `python` for deterministic parsing, transformations, hashing, package inspection, or verification

Do not use shell or Python merely to imitate a safer read/search operation that the host already provides.

## Read-only first

Before creating an infographic artifact or changing workspace state:

- inspect repository/workspace instructions when present
- discover relevant files with read/list/search/grep
- distinguish source files from generated artifacts
- avoid loading vendor, dependency, cache, and build trees without need
- keep evidence, reference, asset, and output locations explicit

## Mutation boundary

Write, patch, delete, move, rename, formatting changes, and mutating shell commands are state changes.

Before mutation, require clear user authorization from the current request or an already approved parent workflow. Preserve unrelated work and prefer focused edits over broad rewrites.

After mutation, read the changed area back when practical and run the relevant verifier when the host exposes an execution capability.

Never write secrets into source, manifests, logs, examples, generated visuals, or release artifacts.

## Infographic workspace behavior

For this Plugin, workspace operations commonly support:

- reading briefs, exports, references, brand assets, SVGs, and source data
- searching a repository for existing design rules or evidence
- writing HTML/SVG/CSS, image manifests, QA reports, and final artifacts when authorized
- patching a focused visual or copy defect after critique
- running render or validation commands when shell execution exists
- using Python for deterministic file processing, hashes, archive inspection, or verification

The parent infographic workflow remains responsible for evidence integrity, identity provenance, narrative taste, visual QA, and final acceptance.

## If a capability is unavailable

Do not claim that a read, search, write, patch, shell command, render, or Python execution happened unless the host produced evidence that it did.

Use another available capability only when it preserves the task semantics. Otherwise return the strongest truthful planning/critique result and mark execution-dependent output as unavailable or `HOLD`.

## Python handoff

When deterministic local computation is materially useful and host-native Python exists, apply the `sandbox-python-executor` Skill. Use actual execution evidence rather than mental simulation.

View saved version →

---
name: linkedin-caption-narrative
description: Use when writing or rewriting LinkedIn captions for repos, plugins, AI workflows, GIFs, infographics, technical ideas, curated collections, tool explainers, belief-correction posts, or first-comment link payloads that need a strong mobile hook and mechanism-first narrative
---

# LinkedIn Caption Narrative

## Purpose

Write high-signal LinkedIn captions that read like a useful explanation someone would stop to read, not launch copy pretending to be conversational

Core principle

**Hook with a real tension, name the thing early, explain the mechanism with concrete nouns, let the visual carry part of the story, and move link-heavy utility into the first comment when that improves the read**

This Skill is designed for technical and AI-adjacent posts where the artifact itself matters: repositories, Plugins, Skills, workflows, models, research methods, animated infographics, GIFs, catalogues, and practical belief corrections

## Use when

Use this Skill when the user asks for any of the following

- a hooky or stop-scroll LinkedIn caption
- a caption for a GitHub repo, Plugin, Skill, workflow, AI tool, model, or technical resource
- a caption that accompanies a GIF or animated infographic
- a curated list or catalogue of repos, tools, or workflows
- a belief-correction educational post
- a recent-signal or research-process post
- a caption plus first comment
- a rewrite inspired by high-signal AI, developer, marketing, GTM, or technical LinkedIn posts

Do not use this as a generic thought-leadership template when there is no real mechanism, artifact, evidence, or practical idea to explain

## Inputs

Resolve these from the user material before drafting

1. **Thing**: what exactly is being shown or discussed
2. **Reader**: who would care and why
3. **Tension**: what friction, misconception, repeated task, or missing context creates interest
4. **Mechanism**: what actually happens
5. **Specifics**: names, commands, steps, inputs, outputs, limits, categories, or verified numbers
6. **Proof**: only evidence supplied or verified
7. **Visual job**: what the GIF or infographic already communicates
8. **CTA**: one useful next action
9. **First-comment payload**: links, setup steps, sources, install commands, or long catalogue entries
10. **House style**: punctuation, banned language, dialect, capitalization, formatting, or other explicit user rules

If a factual claim, number, benchmark, price, star count, license, compatibility statement, performance claim, testimonial, or product behavior is not supported, do not invent it

## Outputs

Return the finished caption first

Return a finished first comment when the user requests one or when links, commands, sources, or a long catalogue would make the caption harder to read

Do not expose pattern names, scoring, internal routing, or drafting notes unless the user asks for them

## Core narrative grammar

The dominant transferable pattern is

**Tension → Named Thing → Mechanism → Specifics → Why It Matters → Visual Bridge → Action**

Not every post needs every stage

The important rule is that each block must advance the idea instead of restating the hook

### 1. Tension

Open on something recognizable and concrete

Strong tension types

- a tool behaves badly in a specific way
- a repeated task has become annoying
- a common assumption is incomplete
- a category changes faster than the research process
- a metric looks good but hides the real problem
- too many resources create a coordination problem
- a technical constraint blocks a practical outcome

Good shapes

- `Most OCR tools choke on messy documents`
- `Most AI tools talk too much`
- `Your page can rank first and still never become the answer`
- `I built so many AI Skills that using them became its own workflow`

Weak shapes

- `AI is changing everything`
- `This tool is amazing`
- `The future of work is here`
- `I found a game-changing repo`

Reject a hook if another product name can be swapped in without changing the meaning

### 2. Named Thing

Name the artifact early

Useful forms

- `Meet {repo-name}`
- `The {repo-name} GitHub repo`
- `This Skill`
- `This Plugin`
- `The stack`
- `The visual below`

Named things reduce vagueness and make the post inspectable

### 3. Mechanism

Explain what happens using plain verbs

Prefer

`A hook grabs Claude's reply after it finishes`

Over

`It improves communication with AI`

Prefer

`Searches recent activity across Reddit, X, YouTube, Hacker News, GitHub and prediction markets`

Over

`It gives you better research`

Mechanism is the credibility layer

### 4. Specifics

Use details that can be checked or acted on

- exact commands
- repo names
- model names
- supported inputs
- output format
- licenses
- hardware
- pricing
- benchmark scores
- star counts
- steps
- concrete use cases

Specificity must serve the decision, not decorate the copy

### 5. Why it matters

Translate the mechanism into one or two practical consequences

Examples

- `If Ollama is down, Claude still works normally`
- `The useful answer can be extracted without decoding four paragraphs first`
- `You stop reopening the same context every session`

### 6. Visual bridge

When a GIF or infographic is attached, use one short bridge at most

Examples

- `The GIF below is how I think about the handoff`
- `The visual shows where each specialist enters`
- `The animation makes the sequence easier to see`
- `The page inside the GIF is an example, not a client result`

Do not narrate every frame

### 7. Action

Choose one practical next action

- open the repo
- install the Skill
- try one Plugin
- save the setup
- inspect the first comment
- answer one practical question

Avoid vague asks such as `Thoughts?`

## Caption archetypes

Choose one primary archetype and stay in it

### A. Repo Explainer

Use when one repo, tool, Skill, model, or Plugin is the subject

Shape

```text
{specific friction}

{one-line solution}

Meet {name}

{verified free/open-source/local/license line when relevant}

Here's what it does:

{mechanism}
↳ {practical consequence}

{mechanism}
↳ {practical consequence}

Why it matters:

{one concrete consequence}

{link location}

P.S. {easy practical question}
```

### B. Stack Catalogue

Use when the value comes from a collection

Shape

```text
{how the collection became necessary}

{count + collection + what unifies it}

{CATEGORY}, {what the category controls}

✦ {item}
✦ {item}
✦ {item}

{one-line category payoff}

{next category}

{compounding line}

{link location}

P.S. {which one would you use first}
```

Critical rule

The collection needs an organizing model

A raw list is not a catalogue story

### C. Operating Story

Use when the interesting part is how work moves

Shape

```text
{repeated workflow problem}

{what changed in the way the work is handled}

{specialist 1}
↳ {job}

{specialist 2}
↳ {job}

{specialist 3}
↳ {job}

The interesting part is the handoff

{how the work moves between them}

{visual bridge}

{first comment}

{question}
```

Good for Plugin stacks, agent workflows, multi-step research, and production pipelines

### D. Belief Correction

Use when a familiar metric or assumption is incomplete

Shape

```text
{strong belief correction}

{why the normal interpretation is incomplete}

That usually comes down to {N} things

1. {factor}
↳ {specific behavior}

2. {factor}
↳ {specific behavior}

3. {factor}
↳ {specific behavior}

{diagnostic question}

{visual disclaimer when needed}

{reader question}
```

### E. Recent-Signal Story

Use when freshness is the problem

Shape

```text
{what goes stale}

{how quickly the category changes}

{named sources and what each contributes}

The interesting part is {comparison or synthesis}

↳ collect
↳ compare
↳ filter
↳ synthesize

{practical use cases}

{visual bridge}

{question about manual source checking}
```

### F. Visual Companion

Use when the visual already carries much of the narrative

Shape

```text
{one-line tension}

{one-line frame for the visual}

{2 to 5 points the viewer should notice}

{what the animation makes easier to understand}

{link or source location}

{one question}
```

Keep this shorter than the visual's information density would suggest

## Hook procedure

Before drafting the body, generate 8 to 12 hook candidates silently

Use at least three different hook mechanisms

- friction
- belief correction
- concrete curiosity
- catalogue scale
- direct utility
- operating problem

Reject hooks that

- could introduce almost any AI product
- depend on hype adjectives
- need the next line to explain what the first line meant
- create suspense around a trivial fact
- promise an unsupported result
- sound written to impress rather than clarify

Keep line 1 compact enough to survive mobile truncation when the language allows it

Roughly 55 characters is a useful default, not a hard law

## Scan rhythm

- keep most paragraphs to one or two short lines
- allow uneven paragraph lengths
- put one main idea in each block
- use whitespace deliberately
- do not turn every sentence into a standalone paragraph when it damages flow
- use section labels only when they make a dense technical post easier to scan
- use `↳` for mechanism, clarification, consequence, or sub-step
- do not use `↳` as decoration
- keep emoji sparse and structural when the writer uses them

## First comment

The first comment has a separate job

It carries utility without slowing the main caption

Use it for

- repo or Plugin links
- installation commands
- setup steps
- source references
- long resource catalogues
- exact paths or technical instructions

### Link index pattern

```text
All links from the visual 👇

1. {Name}
{one-line job}
{URL}

2. {Name}
{one-line job}
{URL}

Start with the one closest to a task you already repeat
```

### Install guide pattern

```text
Setup:

Step 1
↳ {command}

Step 2
↳ {command}

Step 3
↳ {command}

Repo:
{URL}
```

### Source note pattern

```text
Sources / references:

↳ {source}
↳ {source}
↳ {source}

The visual simplifies the idea, so use the sources above for the full context
```

First-comment rules

- do not repeat the whole caption
- do not add a second sales pitch
- do not hide a material limitation in the comment
- preserve exact URLs
- keep names in the same order as the visual when order matters
- if two links use the same display name, distinguish the variants when known

## Visual companion contract

Caption and visual should divide the communication job

Caption owns

- reason to care
- tension
- interpretation
- mechanism that is not obvious visually
- practical consequence
- CTA

Visual owns

- sequence
- topology
- handoff
- comparison
- hierarchy
- before and after
- category grouping
- spatial relationships

Ask two questions before finalizing

1. If the GIF disappears, what useful information is missing from the caption
2. If the caption disappears, what useful information is missing from the GIF

Both answers should contain something important

If the caption merely narrates the animation, compress it

A visual can illustrate a process without proving it

Use `shows`, `maps`, `illustrates`, or `explains`

Do not imply case-study evidence unless the supplied evidence supports it

## Voice and anti-slop rules

- plain English over polished corporate prose
- specific nouns over adjectives
- mechanism before praise
- useful roughness over suspiciously perfect symmetry
- preserve normal technical vocabulary
- no fake urgency
- no invented anecdotes
- no invented proof
- no generic motivational conclusion
- no repeated recap
- no empty superlatives
- no em dash
- avoid repeated `not X, but Y` constructions
- avoid generic transition phrases
- avoid engagement bait disguised as a question

House style outranks this Skill

If the user bans terminal periods, remove terminal periods from visible copy while preserving dots required inside URLs, version numbers, decimals, commands, filenames, domains, and other technical literals

If the user supplies a voice sample, derive cadence and vocabulary from that sample instead of copying example phrasing from this Skill

## Procedure

1. Resolve the inputs and evidence boundary
2. Read `references/reference-examples.md` when the user asks to match the supplied style family or when pattern choice is uncertain
3. Pick one archetype
4. Generate and filter hook candidates
5. Draft the narrative around one primary idea
6. Name the real artifact early
7. Explain mechanism before praise
8. Add only supported specifics
9. Divide the communication job between caption and visual
10. Move link-heavy utility into the first comment when useful
11. Apply the user's house style as hard constraints
12. Read `references/quality-gates.md`
13. Revise until every hard gate passes
14. Return only the requested caption and first comment unless critique is requested

## HOLD conditions

Return a HOLD only when the requested output depends on a claim that cannot be supported without inventing or materially changing the user's approved premise

Examples

- unsupported benchmark or result must remain in the hook
- exact product behavior is unknown and cannot be safely generalized
- a visual is described as a client result but the evidence says it is only an example
- a link or product identity cannot be resolved and exactness is required

Otherwise remove unsupported precision and continue

## Related components

Inside the source repository, this Skill complements the canonical `caption` Skill and its broader caption archetype reference

When the host provides the repository tools, run the existing copy-slop checker where appropriate

```bash
python3 tools/copy_slop_check.py --file <caption.txt>
```

This checker is supplemental

The final narrative judgment, evidence boundary, first-comment split, and visual-caption division remain the responsibility of this Skill

## Research gates

Apply these conceptual gates to every visible draft

- **prose-specificity**: prefer checkable names and mechanisms over generic language
- **voice-preservation**: preserve the writer's natural vocabulary and useful cadence
- **evidence-traceability**: every factual precision must come from supplied or verified evidence
- **visual-alignment**: caption and visual must not contradict each other
- **house-style-compliance**: explicit user rules are hard constraints

Referenced files: 3

View saved version →

---
name: linkedin-infographic-autopilot
description: Run LinkedIn infographic work in autopilot mode by negotiating available host capabilities, using real side jobs and sandbox artifacts when available, and falling back honestly when they are not. Use for end-to-end creation, redesign, animation, or rigorous production workflows in ChatGPT or Codex.
---

# LinkedIn Infographic Autopilot

## Purpose

Operate as the parent production workflow for LinkedIn infographic work. Use the strongest capabilities actually exposed by the current host without inventing agents, tools, renders, background work, publishing actions, asset downloads, or reference inspections.

Quality parity means the same discipline as a strong multi-role creative workflow while allowing a different visual direction for every host and every brief.

Read these local references before execution:

- `references/capability-negotiation.md`
- `references/execution-paths.md`
- `references/side-jobs.md`
- `references/artifact-workspace.md`
- `references/tool-usage-policy.md`
- `references/autopilot-failure-policy.md`
- `references/workspace-agents-bridge.md`
- `references/asset-source-policy.md`
- `references/narrative-taste.md`
- `references/visual-quality-contract.md`
- `references/visual-intelligence-capsule.json`

Read the generated visual-intelligence capsule before creative selection. Apply its hard filters, fixed weights, and slug tie-break, then pass only selected mechanism guidance into production. With no visual reference, reference diagnosis is `SKIP`. Explicit reference intent with evidence that cannot be inspected is `HOLD: reference evidence unavailable` before evidence research. Persistent reference ingestion and source reference media are unavailable in the installed distribution; never claim they were loaded. The capsule is abstract local guidance only.

When repository access actually exists, `demos/` may be inspected as a bounded taste corpus through the contract in `references/narrative-taste.md`. Installed skills do not pretend those demo media are present locally.

The complete blocking visual gate in `references/visual-quality-contract.md` is authoritative for Autopilot. The summary below never replaces or weakens it.

## Autopilot rule

Start every substantial task by observing the capabilities the host actually exposes. Unknown capabilities are unavailable until observed.

Select exactly one runtime path:

- `full-autopilot`
- `tool-rich-sequential`
- `safe-skill-only`

Prefer the strongest safe path. Never pretend that a stronger path ran.

## Executable runtime helper

When `shell_or_code_execution` is observed, use `scripts/autopilot_runtime.py` to make orchestration decisions deterministic instead of relying only on free-form model judgment.

Pass only capabilities actually observed in the current host. Example shape:

```json
{
  "subagents": true,
  "sandbox_write": true,
  "shell_or_code_execution": true,
  "image_inspection": true,
  "web_research": true
}
```

The helper can normalize unknown values to unavailable, select the execution path, generate a bounded evidence-first side-job dispatch plan, and initialize the logical artifact workspace without fabricating artifact files.

Typical commands when execution is available:

```text
python scripts/autopilot_runtime.py select-path --capabilities-json '<observed-json>'
python scripts/autopilot_runtime.py dispatch-plan --capabilities-json '<observed-json>'
python scripts/autopilot_runtime.py init-workspace <task-workspace>/work
```

If code execution is not observed, apply the same contracts directly from the references. Do not claim the helper ran.

## Identity behavior

For every named logo or mascot, apply `references/asset-source-policy.md` before creative direction.

Identity precedence is exact user-supplied official asset, inspectable original-owner source, pinned Vibe SVGs logo mirror for platform/tool logos, verified Lobe fallback when appropriate, then HOLD.

`https://github.com/imMamdouhaboammar/vibe-svgs` is a useful curated source/discovery surface, but its `communityArtwork: true` mascot/scene assets are fan-made/community artwork and must never be promoted to official identity. Official/original mascot requests require exact user/original-owner provenance or HOLD.

Every approved identity becomes identity-locked. Do not redraw, trace, reconstruct, recolor without an approved source variant, distort aspect ratio, or alter wordmark/character-defining geometry.

## Reference and narrative behavior

When inspectable visual references are supplied, derive reusable guidance rather than copying the reference. For every selected mechanism use:

`Evidence -> Observation -> Transferable Rule -> Anti-Rule`

When multiple references exist, assign explicit non-overlapping jobs such as hook, progression, composition, type hierarchy, color, texture, proof, pacing, motion, or payoff. Do not blend them into one vague style and do not copy distinctive subject matter, identity, proprietary artwork, or unique composition signatures.

Before macro layout, apply `references/narrative-taste.md`. Build a real visual progression, commonly `Hook -> Tension -> Evidence -> Turn -> Payoff` when it fits the evidence. Every retained beat records a Reader question and Beat-to-visual mapping. A list converted into cards is not a sufficient narrative.

## Required production sequence

1. Observe runtime capabilities and select the execution path.
2. Run evidence research/inventory first and finalize `evidence/evidence.json` or its non-materialized equivalent.
3. Resolve every required named logo/mascot through `references/asset-source-policy.md`; localize/record provenance when execution allows it. HOLD on unresolved official identity.
4. Only after evidence and required identity boundaries are finalized, fan out independent creative discovery side jobs when real delegation is observed.
5. Generate at least three structurally different creative directions from the finalized evidence boundary, applying reference-transfer rules when references exist.
6. Select the direction and define the primary takeaway.
7. Build the narrative contract from `references/narrative-taste.md`: story shape, hook, ordered beats, Reader question, evidence dependency, Beat-to-visual mapping, turn/payoff, persistent context, reference/demo jobs, anti-rules, originality changes, and necessary motion jobs.
8. Compress copy into visual slots using only approved evidence and narrative beats.
9. Define macro layout before component styling, preserving approved identity assets and persistent narrative context.
10. Run the complete blocking perception preflight from `references/visual-quality-contract.md` and repair only the smallest responsible dimension when a check fails.
11. Build the still when sandbox writes are observed.
12. Run the complete still critique taxonomy, identity-integrity checks, perception tests, severity pressure, and targeted revision routing.
13. Repair blocking still defects, maximum two targeted repair attempts.
14. Proceed to motion only after the complete still gate passes.
15. Implement motion only when the requested output and host capabilities support it; each motion advances reading order, state change, travel, or the narrative turn/payoff.
16. Run render QA using actual rendered evidence when image inspection is observed, including identity integrity and narrative readability across sampled states.
17. Run an independent final verification pass.
18. Deliver artifacts plus a truthful capability/execution summary.

## Side jobs

When real child-agent or equivalent side-job execution is observed, use dependency-aware delegation rather than making the parent do everything serially.

Evidence and required identity resolution are not part of the first creative fan-out. They must complete first because every downstream creative job consumes their finalized boundaries.

After those boundaries are finalized, the creative fan-out may run independent jobs in parallel:

- creative direction exploration
- visual archetype/narrative-shape exploration
- copy compression critique

The parent waits for required side jobs, validates bounded artifacts, selects what survives, and owns the final decision.

When real delegation is not observed, run the same contracts sequentially in the same dependency order. Do not describe sequential role passes as agents.

## Sandbox and artifact behavior

When sandbox or workspace writes are observed, persist intermediate work using the logical artifact contract in `references/artifact-workspace.md`.

Use artifacts to reduce transient-context loss and to make QA inspect the same inputs that the build used.

When write access is unavailable, do not claim HTML, images, GIFs, screenshots, downloaded assets, or files were created. Produce the strongest truthful planning/critique output and return `HOLD` when the requested final artifact cannot be executed.

## Tool behavior

Use tools, apps, search, code execution, image inspection, and publishing connectors only when they materially improve a named job.

Record important tool results in the artifact or verification stage that consumed them.

A tool being described in documentation is not proof that it exists in the current session. Capability must be observed.

## Visual gates

Apply every rule and every PASS/FAIL taxonomy item in `references/visual-quality-contract.md`.

For the default LinkedIn format the gate includes:

- 1080x1350 canvas unless the user requests another format
- roughly 82-92% usable vertical occupancy unless intentional negative space has a clear compositional job
- rejection of unexplained footer/final-zone gaps greater than 120px
- maximum bordered containment depth of two levels
- one dominant visual anchor at feed scale
- explicit macro rhythm and footer reservation
- blocking perception preflight including one-second hierarchy, 100x100 thumbnail, squint/blur, grayscale, negative-space, tangency, brand-off specificity, and effect-subtraction checks
- severity-aware visual-slop pressure that never cancels a hard-gate failure
- rejection of generic UI grammar, nested-card density, weak macro rhythm, weak visual anchor, top-heavy composition, and feed-scale legibility failure
- blocking identity drift for named logos/mascots
- blocking narrative failure when beats do not change understanding or motion merely decorates a weak still

The critic must explicitly return PASS or FAIL for the full taxonomy, including `top-heavy-composition`, `bottom-dead-zone`, `nested-card-density`, `generic-ui-grammar`, `weak-macro-rhythm`, `weak-visual-anchor`, `footer-detachment`, `motion-on-weak-still`, `decorative-motion`, and `feed-scale-legibility`.

Motion cannot begin while any blocking still item or perception-preflight item fails.

If a blocking still defect remains after two targeted repairs, return `FAIL:fixable` or `HOLD` instead of shipping weak output.

## Focused capability routing

When the host exposes the related public skill and the request is focused, prefer the narrower contract:

- `linkedin-infographic-studio` for full production without explicit autopilot orchestration
- `linkedin-infographic-review` for finished-output QA
- `exact-svg-mascot` for protected named mascot identity
- `share-community-demo` for explicit post-verification community publishing consent

If focused skill routing is not exposed, apply the same safety rule locally rather than claiming the skill was invoked.

## Final report

Return:

- selected execution path
- observed capabilities used
- side jobs actually executed
- artifacts actually created
- identity source/integrity summary for named logos/mascots
- narrative shape and narrative-gate verdict
- perception-preflight verdict
- complete still taxonomy verdict
- severity counts and cumulative visual-slop pressure
- targeted repairs actually performed and their responsible dimensions
- motion/render verdict when applicable
- final verdict: `PASS`, `FAIL:fixable`, or `HOLD`

Never claim a tool, agent, sandbox artifact, render, connected app, asset resolution/download, reference/demo inspection, or publication action that did not actually occur.

Referenced files: 12

View saved version →

---
name: linkedin-infographic-review
description: Review a finished static or animated LinkedIn infographic before publishing. Check hierarchy, visual balance, dead space, generic UI patterns, copy, evidence, motion, rendering, and feed-scale legibility without redesigning unrelated content.
---

# LinkedIn Infographic Review

## Purpose

Run a focused pre-publish critique on an existing LinkedIn infographic. Diagnose what is blocking publication, separate required fixes from optional polish, and avoid turning review into an unrelated redesign.

## Inputs

Use the finished HTML, GIF, PNG, screenshots, caption, source material, or evidence the user provides.

If evidence required to validate a factual claim is unavailable, mark that claim as unverified instead of inventing support.

## Review order

### 1. Static composition

Inspect the full artboard before looking at small details.

Check:

- one dominant visual anchor is obvious within two seconds
- the page has a clear macro rhythm from hook to visual relationship to takeaway
- the composition is not top-heavy
- there is no unexplained dead zone near the footer
- the footer belongs to the composition instead of floating far below it
- text remains readable at feed scale
- copy density is solved through hierarchy and editing rather than tiny type

For a 1080x1350 artboard, treat an unexplained vertical gap greater than 120px between the main composition and footer/takeaway as a blocking warning unless negative space has an intentional visual job.

### 2. Perception tests

Run the smallest relevant set against the actual visual:

- **one-second hierarchy test**: identify the hook, primary anchor, and takeaway before reading supporting copy
- **100x100** thumbnail test: the main silhouette and hierarchy must survive at approximately 100x100 pixels
- squint or blur value-mass test
- **grayscale** hierarchy test
- negative-space audit: distinguish intentional framing from accidental dead space
- edge/crop/tangency review
- **brand-off specificity** test: without logos, the composition should still feel specific to this story
- **effect-subtraction** test: removing glow, shadows, 3D, texture, particles, and decorative motion must not remove the concept itself

A failure here does not automatically justify a full redesign. Identify the **smallest responsible dimension** and repair only that dimension.

### 3. Component grammar

Reject generic component patterns when they replace art direction.

Check:

- no more than two bordered containment levels
- repeated cards exist only when repetition is meaningful
- pills, badges, status chips, and tiny uppercase labels have semantic jobs
- no fake dashboards, fake analytics, fake proof bars, or invented metrics
- visual structure fits the story rather than the easiest HTML pattern

### 4. Copy and evidence

Check:

- one primary message
- hook is specific to the subject
- body copy adds mechanism, evidence, comparison, consequence, or action
- takeaway completes the idea instead of repeating the headline
- claims, numbers, logos, product states, and proof are supported by supplied material
- no generic filler or exaggerated marketing language

### 5. Motion when animated

Every meaningful animation must explain at least one of:

- what should I read next?
- what changed?
- where did this item travel?
- which state is active?

Fail decorative motion when it dominates the explanatory motion.
Fail `motion-on-weak-still` when the composition itself should be repaired before animation.

Inspect frame zero, a representative mid-state, the final state, and the loop seam.

### 6. Failure taxonomy

Return PASS or FAIL for each:

- `top-heavy-composition`
- `bottom-dead-zone`
- `nested-card-density`
- `generic-ui-grammar`
- `weak-macro-rhythm`
- `weak-visual-anchor`
- `footer-detachment`
- `motion-on-weak-still`
- `decorative-motion`
- `feed-scale-legibility`

### 7. Severity and pressure

Hard-gate failures remain blocking regardless of score. Classify additional craft findings as:

- `critical`: blocks immediately
- `major`: pressure 3
- `minor`: pressure 1

Block on any critical finding, two or more major findings, four or more minor findings, or **cumulative pressure** of 6 or more. Do not average away a serious defect.

Every non-PASS finding should state:

- severity and pressure
- visible evidence
- consequence at feed scale
- smallest responsible dimension
- exact repair action

Suggested responsibility routing:

- concept/message -> creative direction
- hierarchy/composition/negative space -> layout
- typography -> type
- Arabic/RTL -> Arabic direction when active
- brand/identity -> asset/brand
- copy density -> copy compression
- motion -> motion
- render/runtime -> render QA

## Output

Return:

1. verdict: `PASS`, `FAIL:fixable`, or `HOLD`
2. blocking findings
3. top three repair actions in priority order
4. severity counts and cumulative pressure
5. advisory polish, if any
6. evidence limitations
7. motion/render notes when applicable

Do not return PASS while a severe blocking finding remains or while the aggregate pressure threshold is reached. Do not redesign unrelated content.

View saved version →

---
name: linkedin-infographic-studio
description: Create or redesign a static or animated LinkedIn infographic with evidence checks, verified identity sourcing, narrative taste, concept exploration, intentional typography, macro-layout planning, still-first visual critique, disciplined motion, and final verification. Use for full infographic creation in ChatGPT or Codex.
---

# LinkedIn Infographic Studio

## Purpose

Create feed-ready LinkedIn infographics with the same process discipline expected from a multi-role creative team while remaining self-contained inside an OpenAI skill package.

Quality parity with other hosts does not mean identical visual output. Choose the visual direction that best serves the specific story, then enforce the quality gates in this skill.

Before production, read these local references completely:

- `references/openai-runtime.md`
- `references/role-passes.md`
- `references/asset-source-policy.md`
- `references/narrative-taste.md`
- `references/typography-direction.md`
- `references/visual-archetypes.md`
- `references/copy-quality-contract.md`
- `references/visual-quality-contract.md`
- `references/motion-quality-contract.md`
- `references/visual-intelligence-capsule.json`

Read the generated visual-intelligence capsule before creative selection. It is the packaged reference context: apply its hard filters, fixed weights, and slug tie-break to choose mechanisms, then use only the selected mechanism guidance. With no visual reference, treat reference diagnosis as `SKIP`. If reference intent is explicit but supplied evidence cannot be inspected, return `HOLD: reference evidence unavailable` before evidence work. Persistent reference ingestion and source reference media are unavailable in this distribution; do not claim otherwise. The capsule provides abstract local guidance only.

When a repository checkout is actually available, `demos/` may be inspected as a bounded taste corpus under `references/narrative-taste.md`. The installed package does not pretend those demo media are present locally.

## Use when

Use this skill when the user asks to create, redesign, animate, critique, or materially improve a LinkedIn infographic and the task includes more than one production stage.

For a finished visual review, start at the still/final critique stages instead of rebuilding automatically.

## Inputs

Collect or infer only what can be inferred safely:

- topic, source material, files, URLs, or protected facts
- audience
- one primary takeaway
- desired CTA when relevant
- language
- static or animated output
- optional visual references
- optional brand assets or named AI/tool identities
- explicit typography requirements when supplied

Do not invent missing evidence, product states, metrics, testimonials, logos, integrations, identities, or claims.

## Identity standard

For named official AI/tool identities, apply `references/asset-source-policy.md` before concepting.

Precedence:

1. exact user-supplied official asset
2. inspectable original-owner source with localized integrity record
3. pinned `https://github.com/imMamdouhaboammar/vibe-svgs` file under `svgs/logos/` for a platform/tool logo only
4. verified Lobe asset for supported named AI/tool identities after reading `https://lobehub.com/icons/skill.md`
5. `HOLD: verified identity asset required`

Vibe SVGs mascot/scene records marked `communityArtwork: true` are community/fan-made and must not be called official. They cannot satisfy an original/official mascot request. Use them only when the user explicitly accepts community artwork and the exact commit/path/blob/SHA-256 provenance is pinned.

Do not redraw, trace, reconstruct, prompt-generate, silently substitute, distort, or unapproved-recolor an identity. Final HTML must use a local or embedded copy instead of a remote identity URL.

## Typography standard

Apply `references/typography-direction.md` before copy fitting.

Use explicit user typography when render-safe, then supplied/local font assets, then a curated deterministic system direction. Allowed loading strategies are system, embedded, or local-file. Remote @import and render-time network font requests fail.

## Creative and narrative standard

The output must feel designed for this specific idea rather than assembled from a generic component library.

Before choosing a layout:

1. identify the useful relationship, tension, comparison, sequence, transformation, decision, proof, or reveal
2. read `references/narrative-taste.md` and choose a story shape before layout grammar
3. when references exist, deconstruct selected mechanisms through `Evidence -> Observation -> Transferable Rule -> Anti-Rule`
4. when multiple references exist, assign explicit jobs such as hook, progression, composition, type hierarchy, color, texture, proof, pacing, motion, or payoff instead of blending them indiscriminately
5. generate at least three meaningfully different creative directions
6. define one dominant visual anchor, containment strategy, and negative-space strategy for every direction
7. include an editorial low-containment direction when the story permits it
8. include a diagrammatic or relationship-led direction when a real relationship exists
9. choose an archetype from `references/visual-archetypes.md` or define a justified custom structure
10. select one direction based on comprehension, memorability, evidence fit, identity fit, narrative payoff, reference originality, and feed behavior
11. build a narrative contract with Reader question and Beat-to-visual mapping for every retained beat
12. define the macro layout only after the narrative contract is coherent

Repeated cards are valid when repeated units are the story. They are not the default wrapper for unrelated text. A list converted into cards is not a narrative.

Avoid automatic reliance on:

- nested cards
- decorative pills and badges
- fake dashboards
- repeated rounded rectangles for unrelated information
- tiny uppercase labels as a substitute for hierarchy
- excessive explanatory copy
- decorative 3D, glow, floating objects, or motion with no story job
- reference mimicry that copies a distinctive composition instead of transferring a general mechanism
- fan-made mascots presented as official identities

## Required workflow

Follow the role passes in `references/role-passes.md` in order.

### Phase 1: Evidence

Create an evidence inventory. Mark unsupported factual slots as blocked. Preserve exact user-supplied facts, names, numbers, terminology, and brand constraints.

### Phase 2: Verified identity assets

Create the asset plan before creative direction. Apply the full precedence and integrity rules in `references/asset-source-policy.md`. Record exact source provenance and local/embedded render disposition for every named identity. Identity-locked geometry, colors, wordmarks, and aspect ratio cannot drift downstream.

### Phase 3: Creative directions

Create at least three directions with different structural ideas, not three color variations. Each direction needs a visual hook, copy hook, useful payoff, story relationship, dominant anchor, structural archetype, containment strategy, negative-space strategy, approved identity roles, and motion job when animated.

When references exist, each direction also records selected reference jobs, transferable rules, and anti-rules. Never reuse distinctive subject matter, protected identity, proprietary artwork, or a unique layout signature from the reference.

Do not present three directions that all reduce to a headline plus repeated cards.

Choose the strongest direction and state why it fits the story.

### Phase 4: Narrative and story architecture

Apply `references/narrative-taste.md` before layout.

Define:

- one primary takeaway
- selected story shape
- hook
- ordered beats and reading order
- Reader question per beat
- evidence dependency per beat
- Beat-to-visual mapping per beat
- opening state
- tension/question
- turn/reveal/comparison logic
- final payoff/takeaway
- persistent context
- dominant visual anchor
- containment and negative-space requirements
- density target
- selected demo/reference jobs, transferable rules, anti-rules, and originality changes
- necessary motion jobs only

`Hook -> Tension -> Evidence -> Turn -> Payoff` is a useful default reasoning sequence when it fits, not a mandatory five-screen template.

A viewer should understand what the visual is about within two seconds, but the opening should still create a reason to continue.

### Phase 5: Palette

Resolve a restrained semantic palette with one clear accent and enough personality to feel deliberately designed. Preserve required brand colors without breaking contrast. Do not recolor an identity-locked logo/mascot unless its exact approved source provides that variant.

### Phase 6: Typography

Create a type spec with headline/body roles, optional mono role, loading strategy, fallbacks, role weights, minimum feed sizes, pairing reason, story fit, and render safety.

Do not proceed with a remote font dependency.

### Phase 7: Copy compression

Apply `references/copy-quality-contract.md`.

Write copy by visual slot and narrative beat. Remove repeated explanation before layout. Keep evidence-bearing language precise. Avoid generic thought-leadership filler and vague marketing language.

The visual must carry part of the argument. Do not make headline, subline, body, and takeaway all explain the same idea in different words. Fit copy to approved minimum type sizes rather than shrinking type to rescue dense copy.

### Phase 8: Macro layout and perception preflight

Create an explicit 1080x1350 layout specification before component styling.

Define major zones, proportional heights or bounding boxes, safe margins, alignment, visual anchor, verified identity placements, exact type roles, structural fingerprint, containment strategy, negative-space strategy, expected vertical occupancy, footer reservation, and containment depth.

Map narrative beats to spatial states without turning each beat into a card by default. State why the selected archetype fits the story relationship.

Then run every blocking perception check in `references/visual-quality-contract.md`: one primary focal anchor, one-second hierarchy, approximately 100x100 thumbnail, squint/blur value-mass, grayscale hierarchy, negative-space audit, edge/crop/tangency, brand-off specificity, and effect-subtraction.

A failing check must record evidence, consequence, and the smallest responsible dimension. Repair only that dimension before still construction. Do not reopen unrelated approved stages.

### Phase 9: Still construction

Build the static composition first. The still must communicate the useful idea without animation.

Build macro zones before cards, labels, icons, or micro-decoration. Preserve approved identity assets and type roles exactly.

When HTML is requested, keep the artboard deterministic and fixed at target dimensions. Use semantic HTML/CSS/SVG where appropriate. Preserve editable structure rather than flattening meaningful content prematurely.

### Phase 10: Still critique

Inspect the entire artboard at full size and feed scale.

Explicitly score the complete failure taxonomy from `references/visual-quality-contract.md`, including identity-source, identity-integrity, typography, clean-structure, narrative, and perception failures. Classify non-hard-gate craft defects as critical, major, or minor, calculate cumulative pressure, and include the smallest responsible dimension for each failed item.

Name the top three defects and repair only responsible dimensions. Re-check after repair. Do not proceed to motion while a blocking still defect remains.

Maximum two targeted repair attempts.

### Phase 11: Motion

For animated output, define the motion story before implementing it.

Each motion must explain reading order, change, travel, active state, or the narrative turn/payoff. Follow `references/motion-quality-contract.md`.

Do not compensate for weak static composition with more animation. Motion must not alter identity source, identity geometry/colors, or typography.

### Phase 12: Render and final critique

Inspect frame zero, strongest mid-state, final state, and loop seam when relevant.

Re-run the visual failure taxonomy, perception tests, identity-integrity checks, narrative readability, severity pressure, and motion checks. Verify footer clearance, clipping, feed-scale text, asset loads, font loads, pacing, and whether the primary visual relationship remains obvious.

### Phase 13: Final verification

Return one verdict:

- `PASS`
- `FAIL:fixable`
- `HOLD`

A PASS requires evidence integrity, verified identity provenance/integrity, render-safe typography, coherent narrative progression, a passing perception preflight, a passing still, visual-slop pressure below the blocking threshold, clean creative structure, passing visual critique, and passing motion/render checks when animated.

## Mandatory visual gates

Do not ship when any severe version of these is present:

- unverified or approximated named identity
- official mascot replaced by community/fan-made artwork
- mutable/unpinned identity provenance
- identity geometry/color/wordmark/aspect-ratio drift
- remote identity asset dependency
- remote font dependency
- silent font substitution
- generic headline plus unrelated cards
- narrative beats that do not change understanding
- top-heavy composition
- unexplained bottom dead space
- detached footer
- weak visual anchor
- weak macro rhythm
- excessive nested-card density
- generic UI grammar replacing real art direction
- feed-scale legibility failure
- failed blocking perception preflight
- motion on a weak still
- decorative motion dominating explanatory motion

## Delivery

Deliver the final visual artifact plus a concise summary of:

- selected creative direction
- primary takeaway and narrative shape
- visual archetype
- identity source/integrity summary when named identities are present
- typography direction
- narrative-gate verdict
- perception-preflight verdict
- still critique verdict and cumulative visual-slop pressure
- motion critique verdict when applicable
- final verification verdict

When the task also asks for a LinkedIn caption, keep it specific to the visual's actual insight and provide the first comment separately when a repository link or source belongs there.

Referenced files: 10

View saved version →

---
name: masterone
description: Start LinkedIn infographic work by onboarding reusable project preferences, resolving only route-relevant missing inputs, and selecting the correct OpenAI production or focused skill. Use first when a ChatGPT or Codex user starts or resumes infographic work.
---

# MasterOne

## Purpose

Act as the OpenAI front door for LinkedIn Animated Infographics. Reuse project preferences, avoid repeated setup questions, classify the current request, then hand execution to the narrowest installed skill that owns the job.

MasterOne does not duplicate production logic from downstream skills.

Read `references/sister-plugins.md` before proposing any companion-plugin handoff. Sister Plugins are optional and never core runtime dependencies.

## Project profile

When workspace writes are available, store reusable preferences in `.linkedin-infographics/profile.json` using the repository profile contract. If writes are unavailable, keep the same normalized fields in working context and do not claim they were persisted.

Reusable fields include default language and audience, copyright and footer rules, fonts and local font paths, approved logos and brand assets, references and reference intent, mascot identities and assets, static or animated output, motion preferences, approval rules, and output defaults.

Never infer user-confirmed brand or identity choices from filenames alone. Never treat a community/fan-made mascot as an official identity merely because it resembles or names the product.

## Onboarding

Inspect the current request, project context, and saved profile before asking anything. Ask only for missing inputs that materially block the selected route.

For complete creation, reusable blockers are language, audience, and output mode. Exact footer text is additionally blocking only when the saved preference requires a footer. Fonts, logos, mascots, and references become blocking only when the current task or downstream skill requires them.

Current explicit user instructions override saved defaults for the current request. Persist them as new defaults only when the user indicates that intent.

## Routing

Choose the narrowest installed OpenAI skill:

- complete creation, redesign, animation, or tool-aware multi-stage execution -> `linkedin-infographic-autopilot`
- full production without explicit autopilot orchestration -> `linkedin-infographic-studio`
- finished-output QA -> `linkedin-infographic-review`
- protected named mascot or exact SVG work -> `exact-svg-mascot`
- verified community publishing after explicit consent -> `share-community-demo`
- focused visual-reference or Info-story work -> use the relevant focused path in `linkedin-infographic-studio` or `linkedin-infographic-autopilot`

If a named downstream skill is not exposed by the host, apply its documented boundary locally and state that it was not invoked.

## Sister Plugin routing

Treat every URL in `references/sister-plugins.md` as an optional capability reference only.

Do not infer a companion plugin's name, function, installation state, permissions, or tools from its URL. Do not auto-install it. If the current host actually exposes a Sister Plugin and it clearly owns a bounded supporting job, you may delegate that bounded job while keeping this plugin's evidence and verification rules authoritative.

If the companion is not observed, continue locally. Never claim a handoff occurred when it did not.

## HOLD

Return `HOLD` instead of guessing when a route-relevant reusable input is missing, required footer text is unknown, a requested identity asset cannot satisfy the downstream verification gate, explicit reference evidence cannot be inspected, an official mascot cannot be verified exactly, or the requested final artifact cannot be executed with observed host capabilities.

## Completion

Before handoff, report the selected route, reusable values applied, current-request overrides, and unresolved blockers. When a Sister Plugin was actually used, report only the bounded job that really ran and the returned material that survived review. Then let the selected downstream skill own production and verification.

Referenced files: 1

View saved version →

---
name: sandbox-python-executor
description: Use host-native Python for deterministic file processing, package inspection, hashing, validation, and other executable verification when Python is actually available.
---

# Sandbox Python Executor

Use the current ChatGPT/Codex host's Python execution capability to produce evidence. This Skill is not an MCP server and does not grant a runtime by itself.

## Execute Python when it adds evidence

Use host-native Python for work such as:

- parsing or comparing JSON and generated reports
- inspecting ZIP archives and package boundaries
- computing SHA-256 or other deterministic hashes
- checking file trees, duplicate names, or path safety
- validating SVG/XML or structured output
- transforming user-provided files when local Python is the appropriate tool
- reproducing a deterministic bug or calculation
- running reviewed local validators when the surrounding workflow permits execution

Do not invoke Python just to rewrite prose or simulate a check that can be performed with a narrower host capability.

## Execution contract

When Python is available:

1. actually execute the operation before claiming a result
2. prefer reviewed bundled logic or small deterministic checks over arbitrary untrusted scripts
3. inspect target-repository scripts before running them
4. keep repository access read-only unless the user authorized mutation
5. do not assume sandbox internet access
6. do not expose secrets, tokens, credentials, or unrelated user files
7. preserve generated artifacts the user needs and report their real path/reference
8. include enough evidence to distinguish an executed check from a proposed command

## Infographic jobs

Python may be useful for:

- verifying dimensions, frame manifests, asset hashes, and identity provenance
- inspecting generated package archives
- checking deterministic export metadata
- comparing before/after structured QA reports
- validating file naming and output boundaries

Python does not replace visual inspection. A mathematically valid artifact can still fail narrative, hierarchy, typography, identity, or feed-scale visual QA.

## Evidence to report

Report the relevant subset of:

- operation executed
- pass/fail status
- important counts or findings
- generated path/reference
- SHA-256 when package or asset identity matters
- warnings and checks that could not be executed

Never fabricate stdout, hashes, paths, test counts, generated files, or tool availability.

## If Python is unavailable

Do not claim Python, tests, package validation, hashing, or file transformation occurred. Continue with static inspection only where sufficient and mark execution-dependent conclusions as unverified or `HOLD`.

View saved version →

---
name: share-community-demo
description: Prepare and publish a verified LinkedIn infographic demo to the community gallery through a contributor GitHub pull request. Use only after explicit user consent, rights confirmation, and final verification PASS.
---

# Share Community Demo

## Purpose

Prepare a verified demo for the community gallery and, when authenticated GitHub contribution tools are available, open a contributor pull request. Stop at the pull request. Never merge it automatically.

## Consent gate

Do nothing unless all are true:

- the user explicitly agreed to share the demo
- the final infographic verification verdict is `PASS`
- the user confirms they have the rights to publish the included material

Silence, ambiguity, or a previous decline means zero publication writes.

## Public package

The public demo package contains exactly:

- `demo.gif`
- `index.html`
- `demo.json`

The gallery catalog may also be regenerated as part of the contribution when the repository contract requires it.

Do not copy the whole working directory.

## Export safety

Before any GitHub write, inspect public text and metadata for:

- credential-like tokens or private keys
- local absolute filesystem paths
- signed or temporary private URLs
- private customer/source material
- remote executable scripts that have not been intentionally reviewed
- source prompts unless the user separately consents to publish them

A blocking finding returns `HOLD`. Do not push first and clean up later.

## Metadata

Require contributor identity appropriate for the public gallery, including the GitHub username used for the community namespace and rights confirmation.

Keep sample or concept data clearly identified when it could be mistaken for real proof.

## GitHub contribution flow

When authenticated GitHub contribution tooling is available:

1. create or reuse the user's contributor fork as appropriate
2. create a fresh branch for the demo
3. place the three-file package under the contributor namespace expected by the repository
4. regenerate the catalog only when required by the repository contract
5. commit only the scoped public contribution
6. push the contributor branch
7. open a pull request targeting upstream `main`
8. stop and report the PR URL and validation status

Never push directly to upstream `main` for a community submission.
Never merge the PR automatically.

If authenticated GitHub contribution tooling is unavailable, return `HOLD` with the exact missing capability instead of pretending publication happened.

## Output

Return:

- consent and rights status
- public package path/shape
- export-safety verdict
- contributor fork/branch when created
- real pull request URL when created
- status: awaiting maintainer review and merge

A completed local package is not the same as a published community contribution.