Skip to content
cccskills
FreePublished on GitHub

nika

Turn repeated AI tasks into workflow files with checks for cost, permissions, and structure before execution. Prepare budget limits, offline previews, and execution records that can be checked for tampering.

OriginalShow the original description

Runs repeatable AI work as checked, budgeted workflow files. The agent captures a repeated task as a .nika.yaml DAG, audits cost/permits/schema before a single token is spent, and runs it with tamper-evident traces.

See how to install

Good for

  • Turn repeated AI tasks into reusable workflows
  • Check costs and permissions before execution
  • Preview workflows offline and test them for CI
  • Verify execution records for signs of tampering

Files included (1)

  • SKILL.md5.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Authoring Nika workflows

Nika turns repeatable AI work into files: one .nika.yaml, four verbs, audited before it runs. You author the file; nika check is the oracle; the human runs it.

The loop (always)

  1. Start from a template or example, never from scratch: nika examples list · nika examples show <slug> · nika new --from <template> <file>.nika.yaml
  2. Write the file. Envelope is always nika: v1 + workflow: <kebab-id> + tasks:. Pick models and builtins from the embedded catalogs — nika catalog (providers · models · capabilities · which env var each needs) and nika tools (the nika:* builtins an invoke reaches without MCP); before a run, nika inspect <file> shows the anatomy: tasks · waves · the cost floor.
  3. Check it: nika check <file> (exit 0 = clean · 2 = findings), then nika check --native-strict <file> — it fails on any native-first hint (an exec: a builtin covers).
  4. Repair from the diagnostics — they name the exact task, reference and fix. Unknown code? nika explain NIKA-XXXX.
  5. Repeat 3–4 until clean. Never hand a file to the human that does not pass nika check — and pass --native-strict too, unless every remaining exec: is in the exec ledger (below).
  6. The human (or CI) runs it: nika run <file>. Preview offline with --model mock/echo; run locally with --model ollama/<model>. Inputs ride --var key=value (repeatable · unknown keys refused); a run paused on a nika:prompt resumes with nika run <file> --resume <trace> --answer <task>=<value> (confirm gates take booleans: --answer approve=true).
  7. Pin it for CI: nika test <file> --update writes <file>.golden.json from an offline mock run; nika test <file> replays and compares — deterministic, zero keys.
  8. Prove a run that mattered: every run writes a hash-chained journal to .nika/traces/ — nika trace verify <trace> checks the chain (tamper-evidence), nika trace show <trace> reads the card. Cite the trace, never a memory of the run.

Cost honesty (never hide unknown spend)

  • nika check prints the cost ceiling BEFORE any token: ≤ $X is a ceiling · ≥ $X FLOOR means at least one task is unbounded — name the reason (a missing max_tokens, an uncataloged model, an expression fan-out), never round it to $0.
  • A local model (ollama/…) is unpriced compute, not « free » — say "unpriced", never "$0" or "free".
  • A spend cap rides the run: nika run <file> --max-cost-usd <n> blocks BEFORE the call that would cross the cap.
  • nika explain <file> narrates all of this (waves · cost · touches · how to run) — use it before handing a workflow to a human.

The four verbs (exactly one per task)

  • infer: — an LLM call (prompt, schema? for typed output, max_tokens?)
  • exec: — a shell command (command, capture: text|structured) · last resort: run the native-first interrogation first (below)
  • invoke: — a builtin or MCP tool (tool, args) · HTTP fetch is tool: "nika:fetch", a tool, not a verb
  • agent: — a bounded multi-turn loop (prompt, tools allowlist, max_turns, max_tokens_total)

Native-first (the law)

The order is invoke: nika:* → invoke: mcp:<server>/<tool> → exec:. Before writing ANY exec:, answer in your head:

  1. Which builtin replaces it? nika tools --json is the catalog. HTTP (curl/wget/helper fetch) → nika:fetch · uploads → multipart: · site crawls → traverse: · file plumbing (cat/tee/cp/mkdir) → nika:read/nika:write (create_dirs: true) · JSON shaping (jq/sed) → nika:jq (or an output: binding) · in-place edits → nika:edit · image/speech provider calls → nika:image_generate/nika:tts_generate · image styling (ImageMagick convert / PIL filters / dither scripts) → nika:image_fx (deterministic — same input+args = same bytes, the artifact sha256 joins the trace chain).
  2. Which MCP tool replaces it? A product API deserves an MCP server, never a helper script.
  3. Neither? Name the exact gap — then exec: is legitimate (build tools · git · a product CLI with no MCP surface yet) and goes in the ledger.

Never write a helper script (node bin/helper.mjs …) that wraps HTTP/files/JSON — that is native-first/005, the exact failure class this law exists for.

Exec ledger (mandatory when any exec remains)

Every surviving exec: gets a row in the workflow's header comment:

# EXEC LEDGER ·
# | task | command | why no native path | unlock that removes it |

--native-strict + a complete ledger = a reviewable workflow.

Discipline

  • References: ${{ tasks.<id>.output }} · ${{ vars.x }} · ${{ env.KEY }} · ${{ secrets.X }} (never inline a credential).
  • A task that reads another task's output MUST declare it in depends_on: [<id>].
  • Models are provider/name (ollama/llama3.2:3b local-first · mock/echo offline preview).
  • Timeouts are quoted Go-durations (timeout: "7m") — give local providers ≥300s: thinking models routinely think past 30s.
  • Declare the blast radius: nika check --infer-permits <file> prints the tightest permits: block — paste it in (default-deny from then on).
  • Structured output: give infer: a schema:; add additionalProperties: false for a deterministic shape.
  • Auth rides headers: { x-api-key: "${{ secrets.KEY }}" } (masked · declared in secrets: with its egress: sink) — never exec: curl for the sake of a header.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Handle ActiveCampaign contact and marketing tasks through Rube MCP, a connection for agent tools. Find or create contacts, manage tags and subscriptions, enroll contacts in existing automated workflows, and create follow-up tasks.

  • Finding or registering contacts
  • Adding or removing contact tags
  • Subscribing contacts to lists or unsubscribing them
davepoon/buildwithclaude3.7KUpdated Oct 20, 2026

Research competitors’ live Meta and Google ads to identify opening hooks, offers, calls to action, and landing pages. Receive a sourced creative brief and up to three test ideas adapted to your product.

  • Find angles for new ad copy
  • Plan creative tests using competitor ads
  • Choose a landing page message
davepoon/buildwithclaude3.7KUpdated Oct 20, 2026

agent-analytics

FreeSummary

Add website or app tracking, then use command-line tools to review traffic, signups, drop-off, and returning users across projects. Run A/B tests, which compare alternative headlines or buttons, and inspect results to guide changes.

  • Adding page-view and key-action tracking
  • Reviewing traffic and referral sources across projects
  • Finding where visitors drop out before signup or purchase
davepoon/buildwithclaude3.7KUpdated Oct 20, 2026

Establish rules for when an AI agent should recall past context and save lasting decisions, corrections, preferences, and failures. Works with Markdown files or memory services, preserving decision history and surfacing conflicting records.

  • Carry project conventions into the next session
  • Save user corrections and lasting preferences
  • Record failed approaches and their causes
davepoon/buildwithclaude3.7KUpdated Oct 20, 2026

Audit local AI coding-agent sessions with agenttrace to identify spending, token use, tool failures, and operational problems. Produce readable or structured reports and define pass-or-fail thresholds for automated continuous integration checks.

  • Investigating session costs and token waste
  • Finding repeated tool failures and retries
  • Exporting session reports as Markdown or JSON
davepoon/buildwithclaude3.7KUpdated Oct 20, 2026

Audit saved agent sessions for access to private files and evidence that secret values entered an agent's context. Get findings without displaying secrets, identify keys needing rotation, and inspect Claude Code or Codex sessions in a local report.

  • Check whether an agent accessed .env files
  • Identify keys that may need rotation
  • Audit private-file access by subagents
davepoon/buildwithclaude3.7KUpdated Oct 20, 2026

See all skills by davepoon

Report a problem with this skill