Project standard — cyberine standard and /cyberine:plan --standard (kqjka)

Cyberine bundles a project standard: the areas a board is checked against so that an area nothing pulls in (observability, backup, CI/CD, release, legal, competitor watch) is still seen as missing. It is one data file, plugin/references/project-standard.json, shipped in the npm package and the plugin, read by both the CLI and the plan skill. A project takes the base areas plus every profile that matches it, and a product often matches several.

cyberine standard --list              # the profiles and what each one matches
cyberine standard                     # the base areas only
cyberine standard saas,api            # base + saas + api: profiles compose, comma separated
cyberine standard cli,agent --json    # the same composition as JSON (schema project-standard/1)
cyberine standard saas,nope           # refused (exit 2) with the list of valid profile names
/cyberine:plan ship v1 --standard saas,api   # plan measures the board against base + saas + api
/cyberine:plan ship v1 --standard auto       # plan reads the repo, proposes the matching profiles, then uses them
/cyberine:plan ship v1 --standard ./my-standard.md   # your own file still works; a path is never read as a profile name

Base, for every project: Core, Testing, CI/CD and release, Security, Observability, Docs, Licence and legal, Prior art and competitive watch, Launch.

Profile	Matches	Areas
`saas`	a hosted product with accounts, a web UI and usually billing	16: accounts and auth, tenancy and roles, billing, onboarding, admin and support, notifications, abuse and limits, privacy (includes Vietnam Decree 13), monitoring, data and reliability, performance, environments, analytics, internationalisation and accessibility, go-live, go-to-market
`api`	a public HTTP API, webhooks or client libraries	3: keys and access, contract, SDKs and examples
`cli`	a command-line program or developer tool	4: install and update, platforms, UX, telemetry consent
`desktop`	a desktop or mobile app	4: signing and distribution, OS permissions, compatibility, crash reporting
`library`	code published to a registry for others to import	3: public API, packaging, examples
`agent`	an AI agent, a plugin for a host client, or an MCP server	5: host compatibility, tool contract, safety, evals, cost
`internal`	a tool, job or infrastructure run by and for a team	3: operations, access, handover
`content-site`	a content, documentation or marketing site	4: content, SEO and sharing, performance and accessibility, analytics and consent

Each area carries what it covers and a go-live check, the done-when its tasks roll up to. plan marks every area per project as covered, has-task, missing or not-applicable with a one-line reason, and a missing area becomes tasks or a stated exclusion before the board is written. cyberine standard is read-only and free; it prints keys such as saas/billing and base/security to cite in a brief.

Known Limitations and Deferred Work: the standard is one shared list, not a per-repo override, so a project that disagrees with an area marks it not-applicable with a reason rather than editing the list; cyberine standard prints the areas but does not read your board, so the covered / has-task / missing marking is the plan skill's judgement and is not yet computed or stored by the CLI; profile detection for --standard auto is the session reading the repo, not a deterministic scan; plan is a skill, so there is no cyberine plan command and the profiles are named on the skill or on cyberine standard.