agentsclimarketplace
Sign in

Policy as config

Skill jcdavis131/cursor-agent-skills/skills/policy-as-config

Encode policy — consent mechanisms, data flow, allowlists, retention, feature gates — as config/data rather than hardcoded, so it's auditable, grep-able, and changeable without a code edit. Use when adding a consent flow, a data-sharing path, a feature allowlist, a retention rule, or any policy that compliance/product may need to inspect or change.From its SKILL.md

Install
npx -y skills add jcdavis131/cursor-agent-skills --skill policy-as-config

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

2 things to look at

  • 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 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

3.5 KB, 743 tokens by cl100k_base, as published. Nobody here has run it

Policy As Config

Policy hardcoded in code is invisible (you can't grep a behavior) and expensive to change (a code edit + deploy). Policy as config is auditable (a data field), grep-able, and changeable without touching code. This is the compliance counterpart to infrastructure-as-code.

What counts as policy

  • Consent — the mechanism (opt-in checkbox on /check) and what consented data is used for.
  • Data flow — where consented samples go (data/data-ingest/inbox), what source they're tagged as (data-ingest source: model-gateway-health-checks).
  • Allowlists / denylists — which sites, which providers, which endpoints.
  • Retention — how long data is kept.
  • Feature gates — which features are on for which sites/tenants.

The shape

Encode policy in the fleet/service registry config, alongside the entity it governs:

{
  "id": "model-gateway",
  "domain": "model-gateway.example.com",
  "dataConsent": "Opt-in checkbox on /check; consented samples → data/data-ingest/inbox (data-ingest source: model-gateway-health-checks)"
}

One field encodes: the mechanism (opt-in checkbox), the location (/check), the flow (→ data/data-ingest/inbox), and the source tag. A compliance reviewer reads one field and knows the whole consent story for that site.

Why config, not code

  • Auditable. A reviewer greps dataConsent across the registry and sees every site's consent model in one pass. A code-based consent model requires reading every route handler.
  • Changeable without a code edit. Tightening consent from "opt-in" to "opt-in + explicit confirmation" is a config change, not a code change + deploy.
  • Visible to automation. The fleet SDK reads the config; a drift detector can flag sites missing a dataConsent field.
  • Stable surface. Code changes; policy fields stay named and grep-able across versions.

When to keep policy in code

  • The policy is enforced by code semantics that can't be expressed as data (a complex multi-step auth flow).
  • The policy is truly one-off for a single code path.
  • The policy changes so often that config would lag code anyway.

Most policy is none of these — it's a rule that belongs in config.

Anti-patterns

  • Consent buried in a route handler. "We do consent in the /check page" — invisible to anyone not reading that handler.
  • Data flow implied by code. Samples land in data/data-ingest/inbox because a script writes there, but nothing says that's the intended flow. A config field makes intent explicit.
  • Policy fields without the flow. "dataConsent": "opt-in" — opt-in for what? The field must encode the mechanism AND the flow.
  • Config that duplicates code instead of governing it. Policy in config that the code ignores is worse than no config — it lies.

Pair with

  • metadata-align — the fleet/service registry is the surface where policy-as-config lives; keep it aligned.
  • agent-guardrails — allowlists are policy-as-config applied to agents.
  • readiness-report — a missing dataConsent field on a new site is a "needs your input" item (compliance sign-off).

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most project setup skills give in 743 tokens

Counted across 999 of the 1,637 authors here whose files we hold, read 2026-08-07

  • Ask one question at a timein 29 of 999, across 28 files
  • Detect the package manager from lockfilesin 28 of 999, across 9 files
  • Present findings to the userin 26 of 999, across 5 files
  • Explore current repo statein 24 of 999, across 3 files
  • Update the agent skills block in place if it existsin 24 of 999, across 3 files
  • Install husky lint-staged and prettierin 23 of 999, across 4 files
  • Create the lintstagedrc filein 22 of 999, across 3 files
  • Commit all changed filesin 22 of 999, across 3 files
  • Run lint-staged to verify it worksin 22 of 999, across 3 files
  • Create the husky pre-commit filein 21 of 999, across 2 files
  • Create a prettierrc file if missingin 21 of 999, across 2 files
  • Initialize huskyin 21 of 999, across 2 files

Said here and by no other author read

  • encode policy in config not code
  • encode the consent mechanism in config
  • encode the data flow destination in config
  • encode allowlists and denylists in config
  • encode data retention limits in config
  • encode feature gates in config

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,861. 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.