/linkedin-animated-infographics:masterone

Request: $ARGUMENTS

Purpose

MasterOne is the first user-facing parent workflow for this plugin. It prepares reusable project context, resolves only the missing blockers that matter to the current request, then transfers control to the canonical production or focused workflow.

Read helper/GUIDE.md and helper/router.json before making a routing decision. Machine-readable contracts remain authoritative.

MasterOne does not replace new-post. Complete post production still belongs to the existing new-post parent workflow and its worker sequence.

Use when

Use MasterOne when:

• this is the first LinkedIn Animated Infographics request in a project
• the user wants to create, redesign, inspect, render, study, animate, or share infographic work
• the project has reusable preferences such as footer copy, fonts, references, logos, or mascots
• an AI client needs one entrypoint before selecting a plugin skill or worker
• a prior profile exists and should be reused instead of asking the same setup questions again

A client may invoke a focused workflow directly only when the request is already unambiguous and no reusable project context is missing.

Inputs

MasterOne may consume:

• the user's current request
• .linkedin-infographics/profile.json when present
• current CLAUDE.md / AGENTS.md instructions
• explicit user-provided logos, mascots, fonts, references, files, URLs, and brand assets
• safely observable project paths and existing files
• the route registry in helper/router.json

Reusable profile fields include:

• project name and brand
• default language and audience
• copyright owner, attribution, footer text, and whether a footer is required
• primary, secondary, and Arabic fonts plus local font paths
• approved logo and brand-asset paths
• visual references, reference directories, and whether references are inspiration, strict direction, or ask-first
• mascot identities, asset paths, and automatic-use policy
• static or animated output preference
• motion defaults
• approval and output-directory preferences

Outputs

MasterOne returns or maintains:

• .linkedin-infographics/profile.json
• an onboarding/readiness summary with READY or the exact missing blocking fields
• one normalized route decision from the supported intent set
• a bounded MASTERONE managed section in CLAUDE.md when the client has file-write capability
• the canonical downstream parent or focused workflow selection

Supported downstream intents are:

• create-post
• qa
• render
• design-study
• mascot-animation
• info-story
• share-demo

Procedure

1. Read authority before onboarding

Read helper/GUIDE.md, then helper/router.json.

If .linkedin-infographics/profile.json exists, read it before asking setup questions. Treat it as reusable project preference context, not as evidence for claims inside a post.

2. Inspect before asking

Inspect the user's request and available project context for explicit or safely observable values.

Examples of safely observable context:

• a logo file the user attached or explicitly named
• a local font file already supplied
• a reference directory the user explicitly pointed to
• an existing footer string already recorded in the project profile

Do not infer ownership, rights, attribution, identity, or creative intent from a filename alone.

3. Initialize the profile when missing

When the profile does not exist and file-write capability is available, create .linkedin-infographics/profile.json using schemas/masterone-profile.schema.json as the shape contract.

Start unknown preferences as null, empty arrays, or conservative defaults. Never fabricate values to make the profile look complete.

When file-write capability is unavailable, keep the same profile shape in working context and tell the parent client that persistence is unavailable for this run.

4. Resolve only route-relevant blockers

For create-post, reusable blocking preferences are:

• content.default_language
• content.audience
• linkedin.output_mode

When copyright.footer_required is true, copyright.footer_text is also blocking.

Fonts, references, logos, mascots, and other fields become blocking only when the request or an active downstream gate requires them.

Focused intents do not inherit unrelated onboarding requirements. A render-only request must not be blocked because audience is missing.

Ask one compact onboarding turn containing only the unresolved blocking fields. If the user provides multiple answers together, record all of them and do not ask again.

5. Persist reusable answers

Write reusable answers back to .linkedin-infographics/profile.json when file-write capability exists.

Keep transient post facts out of the profile. Topic-specific claims, one-off metrics, current URLs, and post-specific CTA wording belong to the existing runtime request and downstream evidence artifacts.

6. Keep CLAUDE.md bounded

When file-write capability exists, maintain one marker-bounded section:

<!-- MASTERONE:START -->

The managed section should point to .linkedin-infographics/profile.json and require clients to honor copyright/footer rules, fonts, approved identity assets, mascot policy, reference intent, language/RTL defaults, audience, and output mode.

End the section with:

<!-- MASTERONE:END -->

Replace only text inside those markers. Preserve all other CLAUDE.md content.

Do not copy the full profile JSON into CLAUDE.md.

7. Classify the request

Map the request to one existing intent:

• complete new post or substantial redesign -> create-post
• inspect a finished artifact -> qa
• render an approved HTML artboard -> render
• analyze a visual reference -> design-study
• animate a verified mascot SVG as a focused task -> mascot-animation
• compose or resolve an Info-story without the full post pipeline -> info-story
• publish a verified completed demo after explicit consent -> share-demo

Use the current router contract instead of guessing when route prose and registry data differ.

8. Transfer control

After onboarding is READY, transfer control to the route's existing parent or focused workflow.

For create-post, invoke new-post and preserve its complete production sequence.

MasterOne remains the user-facing coordinator for onboarding and route selection, but downstream workers return to their own parent workflow. MasterOne does not sequence peer workers inside new-post.

9. Re-onboard only when needed

On later requests, reuse the profile automatically.

Ask again only when:

• a required field is still missing
• the user explicitly changes a preference
• a route activates a new blocking requirement
• a stored path is no longer usable
• the stored preference conflicts with an explicit current request

Current explicit user instructions override reusable defaults for the current request. Persist the override only when the user indicates it should become the new default.

HOLD conditions

Return a precise HOLD before route transfer when:

• a route-relevant blocking profile field is missing after inspection
• the profile is structurally invalid and cannot be safely repaired without user input
• a required footer is enabled but its exact text is unknown
• a requested font is required but unavailable under the existing render-safe typography contract
• a requested named logo or mascot cannot pass the existing verified-identity contract
• a requested reference has no usable evidence under the existing reference gate
• routing intent remains genuinely ambiguous after using the request and current profile

Do not invent a value to clear a HOLD.

Related components

• routing authority: helper/router.json
• routing guide: helper/GUIDE.md
• profile schema: schemas/masterone-profile.schema.json
• complete production parent: skills/new-post/SKILL.md
• public deterministic routing helper: skills/post/SKILL.md
• plugin graph: architecture/plugin-graph.json
• module registry: helper/modules.json
• runtime request and caching: scripts/runtime_context.py

Research gates

MasterOne does not add new research claims or quality gates. It activates the route already defined by the helper and preserves that route's existing research gates, local quality gates, verified-identity rules, typography rules, reference behavior, HOLD semantics, and bounded verification requirements.

For complete post creation, downstream new-post continues to apply evidence-traceability and bounded-verification with the rest of its active gate set.