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
npx -y skills add pathak-prashant/cash-framework --skill cash-frameworkAssembled 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:
- Decompose the task into smaller, manageable components.
- 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.
- Evaluate each remaining component on Ambiguity, Sequencing, and Heterogeneity.
- Produce an Architectural Decision Matrix (template below) as part of your recommendation.
- 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.) - 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 KYCis 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
- C gates first. A fired gate resolves the component; no vote.
- 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.
- 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.
- 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:
| Signal | Why code struggles |
|---|---|
| Runtime decision-making under novel conditions | Hard-coded decision trees are brittle and incomplete |
| Synthesis of heterogeneous/unstructured data | Regex, keyword matching, and rule engines miss meaning |
| Natural-language generation under constraints | Template output is robotic; quality gap is measurable |
| Interpreting intent, tone, or domain jargon | Deterministic 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
| Component | C (gate) | A | S | H | Cost Signal | Recommendation |
|---|---|---|---|---|---|---|
| e.g., Fetch User Data | — | Deterministic | Fixed | Structural | Low (no LLM) | Code (API call) |
| e.g., Diagnose Root Cause | — | Ambiguous | Runtime-decided | Synthesis | High (LLM calls) | AI — 3-0: the investigation path is decided at runtime; a hard-coded decision tree breaks on novel incidents |
| e.g., Draft Response | — | Ambiguous | Fixed | Structural | Medium (AI drafts only) | Hybrid (AI-Before-Code: AI drafts, code validates & sends) — 2-1, minority A→AI |
| e.g., Sign Transaction | Reproducibility → Code | — | — | — | Low (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
examples/
- cicd_ai_code_review.md3.5 KB
- clinical_decision_support.md6.9 KB
- customer_support_router.md3.9 KB
- devops_incident_response.md6.4 KB
- ecommerce_search.md8.0 KB
- fantasy_football.md3.3 KB
- fraud_detection.md4.9 KB
references/
- philosophy.md5.0 KB
- research.md7.5 KB
- tco_checklist.md7.9 KB