Claude Code

Most product code at Zynactra is written with Claude Code, and authorization is where a plausible-looking shortcut does the most damage: a role check in a handler, a permission in a token, a list filtered in memory. The zynactra-access plugin prevents that. Its use-access skill loads whenever Claude touches authorization in a product that uses zynactra/access, and walks it through the same steps a person follows:

1. Orient: find zaccess.yaml, the manifests and the stack.
2. Model the permission in the manifest: kind, attributes, actions, scopes, conditions, sensitive fields, org rules.
3. zaccess gen and zaccess test, with real policy tests.
4. Enforce the three checks: route guard, record check, list filter.
5. UI with useCan and <Can>; admin through the admin API only.
6. Verify: generated files current, policy tests and strict-mode service tests passing.

The skill's references/ are these docs, converted to markdown, so Claude reads exactly what this site says for the version the plugin came from.

Turn it on for a product

Commit this to the product's .claude/settings.json. Everyone who opens the repo in Claude Code gets the plugin after they trust the folder:

{
  "extraKnownMarketplaces": {
    "zynactra-access": {
      "source": { "source": "github", "repo": "zynactra/access" },
      "autoUpdate": true
    }
  },
  "enabledPlugins": {
    "zynactra-access@zynactra-access": true
  }
}

zynactra/access is private, so each person needs read access to it on GitHub. A product that also uses @zynactra/ui adds the zynactra-ui plugin the same way.

Or just for yourself

/plugin marketplace add zynactra/access
/plugin install zynactra-access@zynactra-access

Using it

You don't need to mention it. Ask for the work ("add an endpoint to approve expense claims", "who can see salaries?", "review this PR's access checks") and the skill loads. To call it by name, use /zynactra-access:use-access.

What it holds Claude to, beyond the steps:

• No permission, role or scope checks outside access, no permissions in tokens, no hand-written Cerbos policies, no edits to generated files.
• Every resource carries exactly the manifest's attributes plus orgId.
• Default deny everywhere: no fallbacks that allow when Cerbos or the database is down.
• Strict mode on in development and tests; generated constants instead of string literals.
• For every new endpoint, a report of which of the three checks it makes and why any is not needed.

Docs in the package

@zynactra/access ships these docs as markdown in docs/, for the installed version. Go services get the same pages through the plugin.