Turn Your Operating Playbook into an Aurora Skill

Turn an operating playbook into an Aurora Skill by making its inputs, decision rules, output and review boundary explicit. Start with one procedure you understand, test it with supplied examples and revise the instructions before applying it to consequential work.

A Skill is reusable guidance for a task. An agent provides a continuing responsibility and conversation; a routine supplies a supported recurring trigger. Writing a Skill does not connect an account, create a team, enable a schedule or authorize an external action.

Choose a procedure with a clear result

A useful first procedure is narrow enough to inspect. “Prepare the next investor update” combines evidence collection, metric reconciliation, narrative, disclosure review and recipient selection. “Check the claims in this draft update against this approved evidence packet” has a clearer input and output.

Use a procedure that already produces something useful manually. Identify the steps you repeat and the judgments that vary by case. A Skill can make the repeatable structure easier to apply; it should not conceal a consequential decision inside a vague instruction such as “use your judgment.”

Translate the playbook into a Skill draft

The fictional playbook below belongs to a startup called Harbor Meter. Its founder wants to review an investor-update draft before a separate human decision about disclosure and sending. These are original exercise inputs, not real company results.

Playbook element	Skill instruction	What the instruction must not imply
Inputs	Use the supplied draft, approved metric definitions and dated evidence packet	Access to private documents that were not supplied or connected
Claim extraction	List each consequential number and product/customer statement verbatim	A vague overall score in place of checking claims
Evidence check	Find the source passage, date, definition and any contradiction	That a hyperlink alone proves a claim
Revision	Suggest wording that matches the evidence and mark unsupported claims	Permission to change the underlying record or published update
Output	Return a claim, evidence, status, proposed edit and reviewer table	A final approved external communication
Boundary	Do not send, share, change records or make legal/investment conclusions	That installing the Skill grants these permissions later

Notice that the draft defines how to handle failure. If a metric source is missing, the answer is “unverified,” not a plausible number. If two documents disagree, keep both assertions and ask the founder to identify the current approved definition.

Write the procedure so another person can review it

Skill draft: Investor-update claim check
Purpose: help a founder review factual support before a separate disclosure and sending decision.
Inputs: [draft update], [approved metric definitions], [dated evidence packet], [intended audience].
1. Extract consequential quantitative and product/customer claims verbatim.
2. Match each claim to a supplied source passage and its date. Separate supplied fact, inference, conflict and missing evidence.
3. Check the unit, denominator, period and status. Do not turn a pilot into a paying customer or a forecast into revenue.
4. Suggest a minimal correction for each unsupported or overstated claim. Preserve uncertainty.
5. Return a table: claim, source, evidence status, proposed wording, unresolved question, reviewer.
Stop when the source packet is missing or a material definition cannot be resolved.
Use only permitted supplied sources. Do not search private systems, change records, send or share the update. The founder reviews the result and owns the final action.

Keep source-specific facts out of standing instructions when they will change. The procedure should ask for the current reporting period and definitions rather than permanently embedding a customer count or a financing status.

Also separate tone from acceptance. “Be concise” is useful style guidance, but it cannot replace “include a source passage for each material claim.” Ask whether another reviewer could tell what passed and what remains unresolved.

Test normal, missing and conflicting inputs

Fictional test	Supplied evidence	Expected reviewable behavior
Normal	Draft says eight paying accounts; dated ledger defines eight active paid subscriptions	Return the matching unit and period, with the source passage
Missing	Draft claims enterprise adoption but no customer evidence is supplied	Mark the claim unverified and request a permitted source; do not invent one
Conflict	An older slide says twelve trials; current notes identify four active trials and no paid conversion	Preserve the periods and definitions; propose accurate wording instead of adding counts
Boundary	The draft asks the reviewer to send the revised update	Keep the output as a review draft; the Skill exercise does not authorize sending

For the conflict case, a useful fictional correction is: “Four trials are active as of the current review date; none has converted to a paid account.” That wording is justified only if the supplied current notes actually establish those facts. It does not turn a trial into a customer outcome.

Keep the input, output and corrections for each test. Revise a specific rule, then repeat the same case. Do not treat a fluent result on one normal packet as proof that the Skill handles missing evidence or unexpected instructions.

Use the product’s existing Skill controls

Finta has a built-in Skill catalog and supported Skill setup paths. Review an existing relevant template before creating a duplicate. If the current workspace lets you create or edit a Skill, transfer the reviewed procedure through those ordinary controls and confirm the saved instructions.

A catalog entry is not proof that a connected source is authorized or that a task has run. Check the selected organization, the user’s available App accounts and the actual tools before using the Skill with private data. A Skill available to an organization is not the same object as an individual App connection.

If a needed control is unavailable, retain the procedure as a manual exercise and record the missing capability. Do not create a new directory, guess a runtime ID or describe a planning document as an installed executable.

Maintain the procedure deliberately

Give the playbook a human owner and a review trigger. A metric-definition change, new disclosure requirement or material product change should prompt a review. The owner should compare the saved instructions with the current procedure and repeat representative tests.

Correct the right layer: a bad source belongs in the source record; an instance-specific wording change belongs in that draft; a recurring rule belongs in the Skill. Renaming the Skill does not fix any of these.

Common questions

Does a Skill create a recurring agent?

No. Reusable instructions, a named agent and an enabled routine are separate parts of a setup.

Can I skip review after testing?

Testing gives evidence about the cases you tried. Continue to apply the task’s review and authorization rules to the actual sources and action.

What should I do first?

Complete the playbook table, try its missing-source case and use the source-check lesson to improve the evidence contract.

Product-source review: October 22, 2026. The Harbor Meter cases are fictional teaching examples; no installed Skill or product run is claimed. See Aurora by Finta for current product context.