← Operations Web Function

Operations Function Skill

CANDIDATE INTERFACE · Operations Web Function 0.1.0. Turn a recurring organizational responsibility into a complete, auditable operating function made of SOPs, skills, jobs, triggers, context, access, state, approvals, receipts, evaluation, and public learning. Use when someone wants to build an operations function, convert repeatable work into agents or scheduled jobs, connect several skills into a system, define “repeatable excellence,” or publish how an operational capability works.

Canonical owner: operations-web-function:operations-function · Task registration: NOT_A_BOUNDED_TASK

Broader definitive hub · Exact Task Library page: NOT_A_BOUNDED_TASK

Download the complete plugin · Source skill SHA-256: 025c0cc7f67b1c9ee5e4f9085e129eb403d630fdfad2176c70339956c1d7c16c

Candidate source: dennisyu/blitzmetrics-skills · commit: PENDING_MERGE · path: skills/operations-function/SKILL.md

Treat Operations as repeatable excellence: a result can be produced repeatedly, at a declared quality level, with visible ownership and evidence, without depending on one person's memory or availability.

The function factory

1. Name the outcome. State who is served, what changes, and how a stranger can verify completion.
2. Declare scope. List owned services, inputs, outputs, properties, exclusions, owners, service levels, and Definitions of Done.
3. Map the system. Separate durable skills from runtime, jobs, triggers, context/state, access adapters, policy, receipts, and evaluation.
4. Make authoritative sources explicit. Every roster, owner, credential reference, status, and policy needs one source plus a freshness rule. Generate projections rather than maintaining competing lists.
5. Create narrow skills. Give each skill one durable responsibility and clear trigger conditions. Do not embed organization-specific secrets or schedule state in the skill.
6. Create versioned jobs. A job names its skill chain, trigger, permission ceiling, required context, concurrency key, idempotency inputs, outputs, halt conditions, and receipt.
7. Bind the runtime. Connect the adopter's scheduler, event source, context compiler, vault, connectors, approvals, and receipt store. A downloaded skill does not silently activate any of these.
8. Prove the controls. Run known-good, known-bad, negative, failure, timeout, duplicate, rollback, and blocked-vantage fixtures.
9. Start read-only. Expand from observation to authenticated reads, drafts, approved single-target writes, canaries, cohorts, and only then fleet changes.
10. Close the loop. Every novel failure updates the authoritative source, regression test, narrowest skill, job contract, and public-safe evidence ledger.

Canonical registry gate

Before creating a skill or embedding a method in this function, search the canonical marketplace, Task Library, definitive articles, scheduled prompts, and existing adapters. If a skill already owns the method, invoke or improve it; do not copy its instructions into a Web Function fork. A genuinely new bounded task needs a responsibility no existing task owns, an exact task page, a broader definitive hub, literal trigger phrases, a Definition of Done, and a reviewed Task Library registration. Orchestrators and control interfaces are implementations/supporting artifacts, not new Task Library tasks.

Use one master registry/graph with exactly one owner for every artifact: bounded task contracts in the reviewed Task Library source, reusable high-level skills in the merged marketplace, and generated pages, archives, installs, and mirrors as projections. Route new capability intake through $skill-registry and every meaningful run through $recursive-self-improvement-qa. From the plugin root, read docs/MASTER-SOURCE-AND-LEARNING-LOOP.md for the full ownership and propagation contract.

Required states

Keep execution, target health, incident lifecycle, and evidence tier separate. UNKNOWN means evidence is missing; it is never a pass or a score of zero. A timeout describes the observer, not the target. A completed command describes the command, not the production outcome.

Agent completeness test

Before calling something an agent, verify all ten components exist:

• a skill that defines behavior;
• a runtime that can invoke it;
• a versioned job contract;
• a schedule, event, or manual trigger;
• current context and durable state;
• least-privilege access references;
• approval and safety policy;
• concurrency, idempotency, and retry rules;
• independent verification and immutable receipts;
• evaluation, correction, and publication flow.

If a component is absent, label it UNKNOWN or NOT_BOUND; do not hide it inside the prompt.

Public authority standard

Do not write “the most authoritative” as an unsupported claim. Build the evidence that could make others reach that conclusion: versioned releases, stable URLs, real denominators, dated receipts, tests that can fail, corrections, redacted case studies, independent reproductions, citations, and freshness checks.

For the website sub-function, use $operate-web-function and, from the plugin root, read docs/WEB-FUNCTION-SOP.md when the full contract is needed.

This is a generated candidate implementation page, not automatically a definitive article or accepted Task Library task. It delegates to the named canonical owner until reviewed registration and merge receipts exist.