agentleFS
BuilderIOBuilderIO/agent-native/.agents/skills/decisions/SKILL.md

decisions

Skill7.6k starsChanged 5 months agoMITView on GitHub

How to use `@agent-native/core/decisions` for capability-aware classification and scoring. Use when implementing or reviewing decision evaluation, provider ordering, per-provider thresholds, or decision-result caches.

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use decide() to classify or score supplied inputs.

    line 16

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Decisions

Rule

Use decide() to classify or score supplied inputs. It returns a result and never performs, authorizes, or replaces the action selected from that result.

How

Pass an explicit ownerEmail, an input string or array of parts, and named questions to decide() from @agent-native/core/decisions:

import { decide } from "@agent-native/core/decisions";

const result = await decide({
  ownerEmail: "owner@example.com",
  input: [{ type: "text", text: "Please cancel Friday's lunch reservation." }],
  questions: [
    {
      type: "predicate",
      name: "isCancellationRequest",
      instructions: "Does the message ask to cancel a reservation?",
    },
  ],
});

input can be a plain string or contain text, structured JSON, or an image URL. Questions are named and use one of these shapes:

TypeFieldsUse
predicatename, instructionsEvaluate one stated predicate
choicename, instructions, choices: { value: string, description: string }[]Choose among the supplied string values
scorename, instructions, levels: { label: string, description: string }[]Score against 2–10 ordered levels

Provider and model capabilities can differ. Treat question support as capability-aware. Only claim a provider/model supports a question type after that combination has been verified. An ok result includes provider, model, and answers keyed by question name; cached and usage are optional. A not_configured result includes the missing_credentials reason and configured provider list. A failed result has a typed reason and may include provider and questionNames. Handle these statuses as distinct outcomes; never turn a failure into an answer.

Provider routing and caches

Provider order is configurable per workspace. New customer workspaces try Builder Jev first, then a personal Jev key, then OpenAI. Within Jev, the Builder gateway is tried before falling back to a direct key. If no provider is configured, decide() returns not_configured.

getDecisionsStatus() reports credential readiness separately from provider capabilities. The Builder Jev proxy is verified for predicate and choice. Jev score remains unverified and disabled by its capability flag, so decide() skips Jev for score questions and continues to the next configured provider. A Jev-only score request returns failed with unverified_capability. The OpenAI Decisions API supports scores with 2–10 ordered levels; its request and response mapping is covered by documented fixtures.

Key any per-provider threshold or cache by both provider and model. cacheKey enables caching only when supplied. Cache identity includes the owner, organization, provider, model, cache key, input, and questions. The in-memory cache has a 60-second TTL and a 256-entry cap.

Related skills

  • actions — keep action behavior focused and deterministic.

Download now (ZIP)

Trending

More talk lately.about the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 5 mentionsJul 2026: 1 mentionAug 2026: 0 mentionsSep 2026: 4 mentionsOct 2026: 51 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the BuilderIO/agent-native repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about BuilderIO/agent-native

The biggest 5 of 61 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 61

Talked about on GitHub and Bluesky (61 times).

On GitHub · 50

45 more on GitHub

On Bluesky · 11

6 more on Bluesky

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.