agentsclimarketplace

Cash framework

Skill pathak-prashant/cash-framework/skills/cash-framework

Use this skill to evaluate architectural decisions and route each component to its optimal execution environment — traditional Code, GenAI, or Hybrid — using the C.A.S.H. framework (Constraints, Ambiguity, Sequencing, Heterogeneity).From its SKILL.md

Install
npx -y skills add pathak-prashant/cash-framework --skill cash-framework

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

13.8 KB, ~3.1k tokens by cl100k_base, as published. Nobody here has run it

C.A.S.H. Framework

Overview

This skill provides a mental model (the C.A.S.H. Framework) for routing each component of a system to its optimal execution environment: traditional code, GenAI (LLMs), or a hybrid of both. Every LLM call spends "cash" — tokens, latency, maintenance — so each call must earn its place; equally, hand-coding an inherently ambiguous task spends cash on fragile rules and quality gaps.

The evaluation is deliberately neutral: it neither champions nor gatekeeps AI. Instructing an evaluator to advocate for one side measurably biases its conclusions (see references/research.md). State the routing verdict and the reason; let the evidence argue.

Dimension C is a gate, evaluated first. Dimensions A, S, H are votes, evaluated on whatever the gate does not resolve. See references/philosophy.md for design rationale and references/research.md for the sources behind each rule.

Instructions

When the user asks you to build something or architect a system:

  1. Decompose the task into smaller, manageable components.
  2. C — Constraints (gate): resolve hard operational constraints before any qualitative scoring (see the C section below). A component the gate resolves skips the vote entirely.
  3. Evaluate each remaining component on Ambiguity, Sequencing, and Heterogeneity.
  4. Produce an Architectural Decision Matrix (template below) as part of your recommendation.
  5. Cost Checkpoint: for every component marked AI or Hybrid, state the cost trade-off — token volume, latency overhead, integration complexity, maintenance burden — and the cost of NOT using AI (developer hours, fragility of rule chains, quality gap). Any dollar estimate must state its assumptions: tokens per call, calls per day, model tier, cache assumptions, and a dated citation of a current pricing page. (See references/tco_checklist.md.)
  6. Resolve mixed signals with the decision rule below.

When to Use

  • Planning the architecture of a new feature or system.
  • Deciding whether a specific task should be a deterministic script or an LLM prompt.
  • Breaking a large problem into components to determine which need reasoning and which need precise execution.
  • Re-evaluating an existing component when a re-evaluation trigger fires (see "When to Re-Evaluate" below).

When NOT to Use

  • Trivial bug fixes or minor formatting tasks.
  • Straightforward one-liner scripts or simple API calls with no ambiguity.
  • When the user explicitly mandates a specific architecture or tool without asking for an evaluation.
  • Purely creative tasks with no code component (e.g., "write me a poem").

The Four Dimensions

C — Constraints: do hard operational requirements resolve the environment before any scoring?

Check each component against these gates. If a gate fires, the environment is resolved — do not proceed to the A/S/H vote for that component.

  • Latency: sub-100ms response budget on the critical path → Code. Even the fastest mainstream LLM APIs have time-to-first-token of roughly 400–600ms (see references/research.md).
  • Reproducibility: bit-identical output required on every invocation (cryptographic signing, financial calculations) → Code. API-served LLMs are not bit-reproducible even at temperature 0 (batch non-invariance; see references/research.md).
  • Explainability: must a reviewer or regulator be able to state why this specific decision was made (not merely that it was logged)? → Code. Note the distinction: traceability — a complete log of inputs and outputs, as required by EU AI Act Article 12 for high-risk AI systems — can be satisfied by an AI component with full prompt/output logging, and is not by itself a reason to route to code. Only route to code when the requirement is decision-level explanation.
    • Advisory test: a component whose output feeds a human decision-maker does not fire this gate — but only if the review is genuine: the human is accountable for the decision, equipped to independently verify the output, and realistically positioned to override it. A nominal sign-off that is followed by default does not make a component advisory; treat such a component as the decision-maker and apply the gate to it.
  • Data Privacy / Compliance & Deployment Topology: does it process PII, PHI, or data under regulatory mandates (HIPAA, GDPR, SOX)?
    • No → proceed to the A/S/H vote.
    • Yes → check deployment topology before routing:
      • Public cloud LLM (unredacted)Code. Environment resolved.
      • Private/compliant deployment (on-prem, VPC-isolated, BAA-covered) → constraint satisfied; proceed to the vote with a conditional flag.
      • PII-redaction / schema-only prompting (strip PII before the LLM call, e.g. pass table headers instead of row data) → constraint satisfied; proceed to the vote with a conditional flag.
    • Missing Information Protocol: if compliance mandates or deployment topology are unstated and the domain clearly involves sensitive data (finance, healthcare, HR), do NOT assume a private LLM is available. Either assume a public cloud LLM (and route to Code / redaction) or explicitly ask the user for their deployment topology before completing the architecture.

A — Ambiguity: is the component's logic deterministic or ambiguous?

  • Code (deterministic): explicit, rule-based logic — scoring systems, structured formatting, validation. Hand-coding it is cheap and exact.
  • AI (ambiguous): interpreting nuance, intent, tone, sarcasm, or free-text meaning — including summarizing structurally uniform data (hundreds of identically-shaped reviews still need their meaning interpreted). Code for ambiguous interpretation degenerates into fragile regex chains and ever-growing rulesets.

S — Sequencing: is the sequence of steps fixed at design time or decided at runtime?

This is the workflow-vs-agent distinction: workflows follow predefined code paths; agents direct their own next step (see references/research.md).

  • Code (fixed): the steps and their order are known upfront — however large the pipeline, and even with heavy design-time-known branching (if flagged-user → extra KYC is still fixed: the branches were enumerated in advance). Input variance is not sequence dynamism.
  • AI (runtime-decided): the set or order of steps is assembled at runtime from intermediate results — deciding what to do next under novel conditions (dynamic escalation paths, investigation loops, tool selection). Hard-coded decision trees for this break on inputs nobody enumerated. AI decides the plan; code still executes each step (state machines, retries, transactions stay in code).

H — Heterogeneity: can the data be combined by structure alone, or must disparate sources be synthesized?

  • Code (structural): combining data by schema, keys, and types — joins, merges, aggregations — even across multiple sources, as long as no meaning is interpreted.
  • AI (synthesis): correlating heterogeneous, unstructured signals into one conclusion — free-text logs against metrics for a root-cause hypothesis, multi-source evidence into a narrative. If the data is uniform but its meaning still needs interpreting, that routes through A, not H.

Decision Rule

  1. C gates first. A fired gate resolves the component; no vote.
  2. A, S, H vote on everything else — three voters, so no ties:
    • 3-0 → that engine (Code or AI).
    • 2-1 → default Hybrid. The minority dimension names the AI's pipeline position:
      • minority A → AI: AI-Before-Code — AI interprets or drafts, code validates and executes.
      • minority S → AI: AI-Plans — AI decides the plan, code executes each step.
      • minority H → AI: AI-After-Code — code assembles structured inputs, AI synthesizes.
      • minority dimension → Code: code owns that concern (validation, fixed pipeline, or structural merge) wrapped around an AI core; deterministic code remains the authority on its dimension.
  3. Packaging note: a 3-0 AI component may still ship as Hybrid when code must wrap it for safety, validation, or protocol enforcement (clinical guardrails, blast-radius checks) — the AI remains the core engine; say so explicitly. Conversely, a 3-0 Code component may ship as Hybrid when a low-volume LLM call adds distinct value on a non-critical branch.
  4. Always specify where the AI sits in a Hybrid: before code, after code, or alongside it in parallel.

Signals That Favor AI

Neutral doesn't mean timid — when these signals are present, an LLM is typically the lower-TCO choice and the matrix should say so plainly:

SignalWhy code struggles
Runtime decision-making under novel conditionsHard-coded decision trees are brittle and incomplete
Synthesis of heterogeneous/unstructured dataRegex, keyword matching, and rule engines miss meaning
Natural-language generation under constraintsTemplate output is robotic; quality gap is measurable
Interpreting intent, tone, or domain jargonDeterministic parsing needs an ever-growing ruleset

Cost Checkpoint

For every component marked AI or Hybrid, evaluate TCO across three tiers (full checklist: references/tco_checklist.md):

Tier 1a (agent-assessable from the architecture): model tier (smaller/cheaper model sufficient?), integration complexity (prompting, parsing, guardrails), reliability (reproducibility, hallucination risk, testability), and the cost of NOT using AI (developer hours, rule-chain fragility, opportunity cost, quality gap).

Tier 1b (assumption-dependent — state assumptions explicitly): token volume per call and per day, caching potential, response time, peak throughput. Directional, order-of-magnitude estimates only; precise values need production telemetry. Any dollar figure must show its arithmetic (tokens/call × calls/day × per-MTok price) and cite a dated pricing page.

Symmetry rule: the arithmetic standard applies to both sides of a comparison. When an AI design is accepted or rejected against a code alternative, give the code side's infrastructure and build cost the same order-of-magnitude treatment — or state explicitly that the infrastructure is common to both designs and cancels (an LLM-on-every-query design still needs the index, ETL, and delivery pipeline; only the incremental cost decides). Never quantify one branch to the token while writing "low" on the other.

Tier 2 (organizational validation — flag for the user): team prompt-engineering/LLM-ops expertise, model drift and deprecation exposure, observability readiness, internal data-classification policies beyond the regulatory mandates gated in C.

When to Re-Evaluate

The matrix is a design-time verdict, and its inputs drift. Re-run the evaluation for a component when any of these fire:

  • A Code component's ruleset keeps growing to chase edge cases (rule/exception count or change-failure rate trending up) — the A dimension may have flipped to ambiguous.
  • An AI component's realized cost or call volume exceeds the estimate by ~3×, or a stated cache-hit assumption fails in production — the cost signal that justified the routing no longer holds.
  • A model deprecation, a pricing change, or a deployment-topology change (e.g., a BAA-covered or on-prem option appears or disappears) alters a C-gate or cost input.
  • A latency or throughput SLA changes on the component's path.

A trigger prompts a component-level re-vote, not a redesign of the whole system.

Output Format: Decision Matrix Template

ComponentC (gate)ASHCost SignalRecommendation
e.g., Fetch User DataDeterministicFixedStructuralLow (no LLM)Code (API call)
e.g., Diagnose Root CauseAmbiguousRuntime-decidedSynthesisHigh (LLM calls)AI — 3-0: the investigation path is decided at runtime; a hard-coded decision tree breaks on novel incidents
e.g., Draft ResponseAmbiguousFixedStructuralMedium (AI drafts only)Hybrid (AI-Before-Code: AI drafts, code validates & sends) — 2-1, minority A→AI
e.g., Sign TransactionReproducibility → CodeLow (no LLM)Code — gate-resolved

Quick Reference

  • Gate fires (latency / reproducibility / explainability / compliance topology)? → resolved before scoring.
  • Deterministic, fixed-sequence, structural?Code.
  • Ambiguous, runtime-decided, synthesis?AI (AI plans/interprets; code orchestrates).
  • 2-1 split?Hybrid; the minority dimension names the AI's pipeline position.

Examples

See the examples/ directory for worked scenarios, each ending in a full Decision Matrix and Cost Checkpoint:

  • Fantasy Football Team Drafter — code for stats and rule enforcement, AI for drafting strategy.
  • Customer Support Router — code routes and delivers, AI classifies intent and reads tone.
  • CI/CD with AI Code Review — fail-fast-with-code, AI reviews.
  • Real-Time Fraud Detection — the C gate in action: a 50ms SLA routes the hot path to code, freeing the budget for async AI pattern analysis.
  • E-Commerce Search & Personalization — Hybrid at 10M queries/day with worked, cited cost arithmetic; demonstrates all three Hybrid pipeline positions.
  • Clinical Decision Support — compliance topology gating: PHI-bound components to code, AI-assisted diagnosis where the topology permits.
  • DevOps Incident Response — the S dimension in practice: AI plans remediation, code validates and executes.

What ships with it: 10 files

57.5 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.