# Build a Hermes Skill for a Repeatable Editorial Task [Read the original article]() By Garry · Founder Published: 2026-09-29T20:09:33.185Z Updated: 2026-09-29T20:13:22Z 6 min read Categories: Content creation Design a narrow Hermes editorial skill with clear inputs, source rules, examples, stop conditions, and reviewable output. ![A mint folding tool lies beside an open ivory booklet of folding diagrams and a pale blue component.]() ## Key takeaways - Choose one repeated task with a concrete finish line. - Define missing-input behavior and examples of when the skill should not run. - Keep changing product facts in current references rather than durable instructions. A reusable editorial skill should do one job well. “Create great marketing” is too broad to trigger reliably or evaluate. “Turn an approved product explanation into a reviewable carousel outline” is a task with a clear input, a useful output, and a visible boundary. Hermes Agent's skill system can hold that recipe so the team does not reconstruct the workflow in every conversation. The important work is deciding what the skill should know, when it should run, what evidence it needs, and when it should stop for a human decision. ## Choose a narrow task with repeated value Look for a task that recurs often enough to justify a reusable procedure. Good candidates include checking a caption against approved facts, extracting a brief from source notes, or turning a verified explanation into a slide outline. Avoid combining research, strategy, design, account setup, and publication into one first skill. Write the task in a sentence with a concrete finish line. For example: “Return a carousel outline with one supported claim per slide, source notes, and unresolved questions.” This is easier to review than a goal such as “make our content better.” The official [Hermes Skills System documentation]() describes skills as on-demand knowledge documents and explains their structure and loading behavior. Use that current documentation for implementation details. Your [content batching workflow]() can help identify a stable repeated task. A skill is most useful when the underlying process is understood well enough to describe. ## Define the required input and the refusal to guess List what the skill needs: audience, reader question, current facts, approved examples, destination, and relevant media context. Distinguish required inputs from optional preferences. A missing accent color should not block a factual outline, but missing evidence for the central claim should. Explain what to do when information is absent. The skill should ask a precise question, produce a bounded partial result, or identify that the task is outside scope. It should not manufacture a statistic because the output template has a field for one. The [Agent Skills specification]() defines the shared structure for skill metadata and instructions. The specification helps package the skill, while the editorial quality depends on the recipe you write inside it. A useful prompt for designing the recipe is: > Define a Hermes skill for this one editorial task. Specify its trigger, required inputs, source hierarchy, output, review criteria, and stop conditions. Keep product facts in referenced current sources. Do not include publishing authority or unsupported tool assumptions in the skill. ## Write the procedure around decisions A weak recipe says “analyze, write, improve.” A useful one describes what each stage decides. First identify the reader question. Then extract supported claims. Then choose the sequence. Finally check the result against the evidence and intended action. For a carousel-outline skill, require each slide to have a job. One may establish the problem, another explain the method, and another show an exception. Do not force every output into the same number of slides if the argument does not need them. Keep examples close to the decision they teach. A short example of narrowing an unsupported claim is more useful than a long sample article with no explanation. Mark examples as examples so their facts do not leak into unrelated work. The [carousel workflow guide]() can provide production context. The skill's specific purpose remains the outline, not the entire design and publishing process. ## Separate references from the core instructions The main skill should be readable enough to understand quickly. Put detailed product documentation, voice examples, and format references in supporting material where the system's documented structure allows it. The core instructions should say when each reference is relevant. Do not load every reference for every task merely because it exists. A factual review may need current product notes, while a tone revision may need approved examples. Clear reference selection reduces noise and makes the workflow easier to inspect. Use the [brand voice guide]() for durable expression preferences. Keep changing facts such as prices, dates, and platform availability in a current source record with an owner and review date. If a skill uses tools, document the actual required capabilities. Do not assume browsing, image generation, or a Caroush connector is present in every Hermes installation. A manual handoff can be an explicit output when the connection has not been verified. ## Add examples of when the skill should not run A narrow skill needs a clear boundary. A carousel-outline skill should not activate for a request to troubleshoot OAuth or delete a social post. A fact-checking skill should not rewrite source evidence to match the desired campaign. Write a few near-miss examples. They help clarify the trigger and reveal whether the description is too broad. The difference between “draft a carousel” and “publish this approved carousel” is consequential even though both contain the same content noun. For an illustrative test, provide a brief with a missing product availability fact. The skill should produce the supported outline and flag the unresolved claim, or stop the dependent part. It should not quietly turn a proposed feature into a released capability. Another test can supply a style example with an old price. The skill should borrow the writing principle without importing the price. These small cases reveal whether the source hierarchy is working. ## Review the output as an editor Check the first few results manually. Is the reader's problem clear? Does every material claim have support? Are the slides distinct? Are unresolved questions visible? Does the output stay within the skill's scope? Do not accept a result simply because it follows the template. A field called evidence can contain an irrelevant link. A slide labeled example can still invent a customer result. Read the meaning of the content, not only the presence of sections. Use your [approval workflow]() to define who accepts the skill's output. A skill can prepare a reviewable artifact, but it should not make itself the final authority for public claims. Keep a short note of repairs. If the same mistake appears twice, adjust the relevant instruction or example rather than appending a broad warning at the end. The recipe should become clearer, not merely longer. Keep a worked example that demonstrates an incomplete input. Show the required output when a brief asks for a result the sources do not measure: the skill can explain the supported process, remove the unsupported outcome, and list the question for the product owner. This teaches a useful response to uncertainty rather than rewarding completion at any cost. Also include a successful simple case. A skill should not become so focused on exceptions that every ordinary task produces a long warning. When the inputs are complete and the task is within scope, it should return the requested artifact directly, with concise source notes and a clear review state. Both behaviors are part of a well-defined recipe. ## Package the skill for maintenance Give the skill a specific name, description, owner, and version record using the supported format. Record the sources and tests used to review it. If a product fact changes, the owner should know which reference to update and which test to rerun. Do not overwrite a working skill casually during a broad content task. Changes to the reusable recipe affect future work, so review them as a separate modification with examples of the expected behavior. When the outline is approved, use Caroush's [AI carousel generator]() or other [content tools]() for production. This does not establish a verified Hermes-to-Caroush MCP connection; consult current client documentation before relying on a direct route. The useful result is a small editorial capability the team can explain and test. Hermes handles the repeatable procedure, while current sources and human judgment determine whether the content is ready to move forward. ## Sources - [Skills System]() - [Agent Skills specification]() ## Frequently asked questions ### What is a good first editorial skill? Choose a narrow task such as checking a caption against approved facts or producing a source-backed carousel outline. ### Should one skill handle the whole marketing workflow? Start smaller. Research, drafting, design, authentication, and publication have different inputs and review requirements. ### Can a skill assume a Caroush MCP connection exists? No. Document actual tool requirements and use a manual handoff unless the current client and server setup has been verified. ### How should missing facts be handled? Specify whether the skill should ask a precise question, produce a bounded partial result, or stop the dependent work without guessing. ## About the author Garry Gaurav Sapkota builds Caroush, a workspace for creating, scheduling, and publishing social content. - [https://x.com/gauravsapkotanp]()