SkillCDN Pack

Card news from a brief, in a reference format, rendered from code

A format spec and a topic brief go in; a carousel of PNG slides comes out, with its caption and its credits. Every slide is one of the format spec's slide types, measured on a reference account or designed from one at the user's pick: its anatomy, how it treats its photo (cropped full-bleed, or a captured frame kept whole with its marks), which text is the account's own and which belongs to the material it shows. The type is chosen by what the slide carries and the sequence is the spec's build; this skill has no layouts of its own, because the user holds the result against the format they chose and a type the format does not use is the first thing they see. The script is one thread from the brief's published angle, written at the format's counted density and in its register, on only the slides whose type carries text of the account's. Every image is the brief's, placed as its type treats it and credited in the caption. The page is HTML the agent can show and re-export in a minute, and every PNG is looked at at phone size before it is delivered. Nothing on a slide comes from anywhere but the brief; nothing is posted.

How the user is involved

• Questions: only where the inputs are: the spec folder and the brief folder, when the request does not point at them and they are not beside the run, and, with no spec, the reference where the request names none ("Which account or post should ours look like? Its link, or say you have none") and which route to one (Inputs). Nothing else is asked; the build, the slide count, the fonts and each slide's type are derived from the spec and shown.
• Checkpoints: the slide plan (the thesis, the thread, each slide's type from the spec, its text and its image), and the render review (every PNG attached, with what the review changed). Each is one short message; "OK" continues.
• Go-ahead: when the user says to go ahead alone, both checkpoints are skipped, and with no spec the recommended route to one runs, the study's recommended candidate standing as the reference where none was named, said so, and falling to the next way in its order where one cannot run (Inputs, "Format spec"); the delivery still attaches every PNG and says which route the format came by.
• Changes mid-run: "too much text", "the tone is off", "this is not the account's format" re-enter at the plan and apply to every slide, not the one named, within the spec's ranges (fewer sentences, the rest to the caption); where the user wants less than the spec's floor, the format is the matter, and the plan says so and offers the design variations on the density, or the spec's counts changed at the user's word; the last one means the spec was not followed, so the plan is held against the spec's types and build again, slide by slide, before anything is rendered. "This cannot be seen" re-enters at the plan's image step for every slide. A photo swap re-enters at the build. "Not punchy", "no hook", "nobody will read this" re-enter at the plan with the thread, the concept variations run first on the user's word (Inputs, "Concept"); a draft that came back as "too much text" and then as "the first was better" was asking for a hook, not for fewer lines. "More aggressive", "neutral", "take our side" re-enter at the plan with the stance and the tone changed in the brief.

Requirements

Check Node.js, the network (one request to the font path the spec names, or to a fonts CDN while there is no spec yet) and a Chromium-family browser (an installed Chrome or Edge, or playwright-core's own Chromium, proved by a launch and not by a look at the disk: by channel where playwright-core is already resolvable, borrowed through PLAYWRIGHT_FROM or in card-news/tools/, else one bare --headless=new run with a profile folder of its own, as headless.md "The bare browser" says) before the first message, as headless.md "The check before the first message" says; without Node.js or a browser, stop and say what to install. playwright-core itself is borrowed or installed into the tools folder before phase 4 launches it, said in a line, and a launch that still fails stops there with the install line. page-and-export.md, the page and the review, is read when phase 2 comes. What the card-news skills share is in the repository's document set docs/card-news/; the two pages this skill reads from it, format-spec.md and topic-brief.md, are included and arrive with this skill wherever SkillCDN serves it, and so is rendering-html.md from the repository's document set docs/browser/, which holds how any page the agent writes is served, exported and looked at; its headless.md is linked from the export. A copy of this directory and the area's plugin lack the included pages, which are all in sets of the repository's docs/, the plugin also headless.md, and a mount of one area or one skill cannot read the linked one: say so, fetch them from docs/card-news/ and docs/browser/ of the repository this skill comes from (for this pack, github.com/skillcdn/skills), and otherwise read the spec and the brief as the files are. How the tools behaved in runs of this skill is in tool-notes.md; read it before phase 1.

The area's rule to match what exists takes this form here: the format spec is what exists, measured on a reference or designed at the user's pick, and every slide takes its type, its anatomy, its density and its register from it; the facts are the brief's, from the articles it read, and its images come from where the articles point (their photographs, the clip or footage they cite, the subject's public pages), each with the credit the brief records, used as the account itself publishes such material. The canvas, the slide types and the caption's form come from the spec, which measured them on the account and looked up the platform's documented size.

Inputs