I don't like a lot of the Remotion work on my website. I think we can do much better, and asking an agent to make the next one more impressive would leave me asking the same thing again on the article after that.
So I asked for a skill.
A Markdown file, some references, and a set of procedures an agent can use when it has an actual explanation to build. I want the research to survive the animation. The next worker should inherit what the previous worker learned about making a chart legible, staging a reveal, or showing how a constraint changes a decision.
I also gave the website a limited Higgsfield budget. That makes the choice concrete. A generated image consumes generation credits. A graphic authored in code can be revised without another Higgsfield call. It still takes work, and somebody has to inspect the result. The work leaves editable source behind, which the credits do not.
My instruction was to treat this as an investment. I want to find out what a free Markdown file is worth by watching what it helps produce.
There's a stupid version of that experiment where I count the words in the skill, multiply by an imaginary consultant's hourly rate, and announce that we've created a six-figure intellectual asset. That would price a claim before anything had happened against it.
The comparison I want starts with a claim in an article. Give it a clear visual treatment. Keep the code and the instructions that helped the author choose that treatment. Then give a different claim to the next worker and see which parts actually carry over.
That's a test I can run.
Different specialists solve different parts of the shot
I asked the team to find the level-99 black magician of Remotion. The research produced several people with different useful specialties, which gives me more to work with than a crown somebody assigned from a search result.
Jonny Burger's Spring Loaded project makes its construction visible. He traced a shape into an SVG path, sampled positions along that path, and animated the result with spring motion and changing colors. The source also names a performance weakness in its drawing method. That is useful teaching material: a finished idea, the decisions that produced it, and a limitation its author bothered to leave on the record.
William Candillon's work supplies another route. Remotion's Skia documentation points to his tutorial for bringing that drawing engine into video. The Three.js integration documentation credits Björn Zeutzheim for its research and initial implementation. These are specific contributions I can trace. They don't establish that either person is the best at every kind of explanatory graphic.
Vincentwei1021's video-shotcraft is closer to the organized craft library I had in mind. It connects shot recipes to implementation and previews. An author can inspect how a treatment was built instead of copying a screenshot and hoping the camera behaves. Its source also has a license, which needs to stay attached when code is reused.
The field widens beyond Remotion. Pixar's Incredible Cinematography discusses how camera and lighting decisions serve a scene. I can study those decisions without claiming Pixar uses my video framework or putting somebody else's film art on my website.
That's the research direction I wanted. Borrow the parts that someone has already understood deeply, identify what each part is good for, and keep enough of the source trail that another person can check the choice. A glowing background alone won't get me there.
Open the reference that answers the problem in front of you
I asked for separate procedures because a sales funnel, a fluid field and a software demonstration need different kinds of judgment. An agent making all three from one general instruction to produce cinematic graphics will have to invent the missing decisions three times.
The draft skill begins with a short selection page. That page sends the worker to a category procedure, and the procedure opens the deeper concepts needed for that job. We can keep a shared explanation of timing in one place while giving a funnel its own questions about who moves between stages and what the widths represent.
The working categories cover quantitative graphics, processes, marketing funnels, software demonstrations, ambient scenes, scientific simulations, fields and flows, spatial anatomy, maps, evidence and chronology, kinetic typography, and audio-synchronized narrative. This is our practical filing system. It is not a scientific finding that the universe contains twelve kinds of animation.
A funnel starts with a population and an event. Who entered? What happened before somebody moved to the next stage? Do the figures count the same cohort over the same period? The procedure should make the author answer those questions before drawing a shape that gets narrower toward the bottom.
A software demonstration needs a different check. The screen state has to be real, and the viewer has to see the action that caused the result. A camera move that skips the action can make a feature look mysterious even while making the video look expensive.
A scientific simulation has a much heavier obligation. It needs a model, assumptions, units and a method for advancing the state. Mark Harris's GPU Gems chapter on fluid simulation describes a sequence of numerical operations that includes moving the field, applying forces and solving for pressure. A swirling texture doesn't become that calculation because I put a physics word in its caption.
The shared references are where the investment can accumulate. A correction to mobile typography should improve every procedure that depends on it. A better explanation of chart baselines should be available to the next author of a funnel as well as the next author of an infographic. I don't want copies of the same advice scattered through twelve files, slowly disagreeing about what good means.
I also don't want every worker reading every file. Part of expertise is knowing which instrument the situation calls for. A usable skill should help make that choice.
A frame has to explain something
I set a ceiling of four hundred words per creative across the website, with a much denser treatment for a leading article. That is a constraint on the work, not a reason to put a glowing rectangle after every few paragraphs.
A graphic earns its place when it makes a relationship easier to understand. A change over time can become a visible transition. A constraint can become a boundary the subject reaches. Two measurements can share a scale so the difference stops being something the reader has to calculate in their head.
Those choices also decide what needs to stay still. Moving every label while asking somebody to compare two values is a pretty effective way to make comparison unpleasant. The production decision begins with what the reader needs to see, and the motion follows that.
I want the phone version designed as a phone version. Shrinking a desktop composition shrinks its text too. An author may need to stack the comparison, remove secondary labels, or break a sequence into several readable states. That is a different composition using the same underlying claim.
The static version has a job as well. Somebody who cannot play the animation should still get a meaningful frame. A beautiful reveal that leaves its poster on an empty background has failed that reader before the reveal begins.
These are things a reusable procedure can ask the author to decide. It can also carry the failure that taught the rule. An instruction to make labels readable is easy to agree with. A record of a label that became illegible when the design was delivered into a phone column gives the next worker a mechanism to check.
The current production record is narrower than the experiment I described. Eleven comparison figures exist. They are one template carrying eleven rows of data, not eleven separate designs, and each row renders in a wide arrangement and a tall one from the same component. The figures have been rendered and the pixels have been looked at. Nobody outside the work has accepted them, which is a different fact and a smaller one. The source proves the intended relationships are implemented in code and legible at delivery size. It does not prove that the skill improved the output.
Count what the method actually saves
I called Remotion free because producing another code-authored graphic doesn't require another Higgsfield generation purchase. There are still costs to keep separate.
The Remotion license permits free use for individuals and for-profit organizations with up to three employees, along with other listed eligible cases. It requires a company license outside those categories. It also flags an upcoming license change. A team should check its own eligibility instead of copying my word free into a procurement decision.
Somebody still has to research, write code, review the composition and render the output. Machines and storage don't become free because a bill is included in another subscription. The reusable instructions have an initial authoring cost, and maintaining them has a cost too.
Higgsfield has work around the generation as well. An image needs an idea and a prompt, somebody has to inspect it, and a rejected result doesn't become a useful creative because the provider successfully returned a file. The useful denominator on both sides is an accepted piece of work.
I would count an animation's desktop version, phone version and poster as one creative with three deliverables. Otherwise I could improve the economics by exporting more files. That would be an accounting trick with a render button.
Only some of this work replaces anything. A code-authored illustration that does the same job as a generated still can support a comparison of what each route consumed. An animation explaining a process may do something the still never did. Calling it an avoided image purchase would assume I was going to buy a comparable image in the first place.
So the credit calculation needs an explicit population: count accepted code visuals that replaced a genuinely comparable still, then multiply by the verified generation cost of those stills. That estimates the credits the other route would have consumed. Cash saved needs one more fact: that a purchase I would otherwise have made was avoided. Credits already included in a subscription complicate that claim.
The same discipline applies to time. If the first composition took substantial effort and the next one used its code, I would keep the initial effort in the record. I would also separate changing an existing title from explaining a new mechanism. Those are different jobs, and putting them into one average would flatter whichever method got the easier assignments.
| What I want to learn | What would count as evidence |
|---|---|
| Did the code route consume fewer image credits? | Actual provider receipts and a defined set of comparable accepted visuals |
| Did the skill reduce repeated work? | A later real assignment that reused a specific instruction or implementation, with its revision and review work recorded |
| Did the graphics get better? | The old and new treatment of the same claim, inspected at the sizes readers receive |
| Was the initial investment recovered? | Observed reuse benefits compared with the research, authoring and maintenance cost that produced them |
The accounting record is still mostly empty. No Higgsfield job was run, no paid provider receipt exists, and authoring time, render cost, storage cost, review cost, accepted-output count, quality change, reader effect, and savings were not measured. What the batch shows is source and a render: eleven comparison figures share one template, and every one of them has been rendered wide and tall and inspected. None of them has been accepted by anybody but the people who made it. There is no savings or payback claim to make from that record.
Give the next worker something it can use
A skill that nobody can find has the same practical value as a useful function nobody calls. I asked for this one to be visible to agents across the Applications directory so that a worker assigned an infographic can reach the relevant procedure without knowing which previous conversation created it.
It also needs to be editable. A later author may find a better way to show a field, or discover that a recommended technique fails under the version of a library the project actually uses. That finding belongs beside the instruction it corrects. Keeping the old advice untouched and adding another warning somewhere else would leave the next worker to discover the contradiction again.
I can use a generated image when an image is the right result. I can use code when the claim benefits from an editable structure, a repeatable state or controlled motion. I want the research to make those choices better and the next piece less dependent on rediscovering everything.
Retained judgment is what I am willing to invest in. A Markdown file is a convenient place to put it. The next assignment is where it has to earn its keep.
The observed outcome is smaller and more useful than a valuation headline. Eleven claim-specific figures now exist, built from one template with a row of data each, and every one renders in both a wide arrangement and a tall one. No accepted batch receipt, measured reuse event, or public skill link exists yet. The experiment has started and the valuation has not. A later assignment still has to show whether the retained judgment reaches new work.