Help us improve
Share bugs, ideas, or general feedback.
From chittyos-devops
This skill should be used when building, auditing, deploying, or certifying any ChittyOS service or artifact. It covers compliance auditing ('check compliance', 'audit this service', 'is this compliant?'), scaffolding new services ('scaffold new service', 'generate CHARTER.md/CHITTY.md/CLAUDE.md'), monitoring deployed health endpoints ('check health', 'monitor services', 'service status'), and certification ('certify', 'ChittyCertify', 'what badge level?'). Also trigger proactively when creating new ChittyOS services, modifying wrangler configs, writing CHARTER/CHITTY/CLAUDE docs, checking canonical compliance, registration readiness, or preparing for deployment.
npx claudepluginhub chittyos/chittymarket --plugin chittyos-devopsHow this skill is triggered — by the user, by Claude, or both
Slash command
/chittyos-devops:chittyos-complianceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Full lifecycle compliance management for the ChittyOS ecosystem: audit existing services, scaffold new ones, monitor deployed services, and certify artifacts.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Explores codebases via GitNexus: discover repos, query execution flows, trace processes, inspect symbol callers/callees, and review architecture.
Share bugs, ideas, or general feedback.
Full lifecycle compliance management for the ChittyOS ecosystem: audit existing services, scaffold new ones, monitor deployed services, and certify artifacts.
| Mode | Trigger | Purpose |
|---|---|---|
| Audit | "audit", "check compliance", "is this compliant?" | Full compliance check against ChittyOS standards |
| Scaffold | "scaffold", "new service", "generate templates" | Generate compliant CHARTER.md, CHITTY.md, health endpoint, wrangler config |
| Monitor | "monitor", "check health", "service status" | Hit deployed *.chitty.cc/health endpoints, verify live compliance |
| Certify | "certify", "certification", "ChittyCertify" | Evaluate artifacts against certification criteria, assign badge level |
Every ChittyOS service MUST satisfy these requirements.
| File | Purpose | Frontmatter Required |
|---|---|---|
CHARTER.md | Service charter — mission, scope, dependencies, API contract, ownership | Yes (type: policy) |
CHITTY.md | Service badge & one-pager — identity, architecture, certification badges, ChittyDNA, ecosystem position. The service's "work badge" at a glance. | Yes (type: architecture) |
CLAUDE.md | Developer guide — commands, dev workflow, patterns, gotchas | No |
CHARTER.md, CHITTY.md, and CLAUDE.md form a coordinated triad — the charter (policy), the badge (identity), and the guide (developer docs). When auditing or creating these files, verify cross-document consistency:
{name}.chitty.cc) must be consistent across all threestatus field in frontmatterWhen updating any one document, check the other two for consistency. When scaffolding, generate all three together to ensure alignment from the start.
All chartered documents (CHARTER.md, CHITTY.md) require this metadata envelope. CHARTER.md uses type: policy, CHITTY.md uses type: architecture:
---
uri: chittycanon://docs/{domain}/{type}/{identifier}
namespace: chittycanon://docs/{domain}
type: policy|spec|procedure|registry|architecture|catalog|summary
version: semver
status: DRAFT|PENDING|CERTIFIED|CANONICAL|DEPRECATED|ARCHIVED
registered_with: chittycanon://core/services/canon
title: string
certifier: chittycanon://core/services/chittycertify
visibility: PUBLIC|INTERNAL|CONFIDENTIAL|RESTRICTED
---
Domains: tech, legal, ops, exec, gov
chittycanon://core/services/{service-name} (kebab-case){service-name}.chitty.cc or {short-name}.chitty.cc| Tier | Layer | Examples |
|---|---|---|
| 0 | Trust Anchors | ChittyID, ChittyTrust, ChittySchema |
| 1 | Core Identity | ChittyAuth, ChittyCert, ChittyRegister |
| 2 | Platform | ChittyConnect, ChittyRouter, ChittyAPI |
| 3 | Operational/Service | ChittyMonitor, ChittyFinance, ChittyLedger |
| 4 | Domain | ChittyEvidence, ChittyIntel, ChittyScore |
| 5 | Application | ChittyCases, ChittyPortal, ChittyDashboard |
Every service MUST implement:
GET /health returning {"status":"ok","service":"<name>"}GET /api/v1/status returning service metadataAll 5 types MUST be included in any entity type validation. Claude contexts are Person (P, Synthetic) — NEVER Thing (T). "Entity type" is the field name; "Entity" is NOT a valid type value.
CHITTY_AUTH_SERVICE_TOKEN (not CHITTYCONNECT_API_TOKEN or variants)jose library for JWT/JWKS on edge (not jsonwebtoken)*.chitty.cc + localhost[vars]chitty* conventioncompatibility_date: within 6 months of today[[tail_consumers]] with service = "chittytrack" for observabilitypackage.json name must match the service nameBefore auditing, scaffolding, monitoring, or certifying ANY service, first discover its ecosystem context. Do NOT build or evaluate in a vacuum.
curl -s https://registry.chitty.cc/api/services | jq . — get the full service catalogCHARTER.md (API contract, endpoints), CHITTY.md (architecture, ecosystem position), and CLAUDE.md (dev patterns, integration examples)/Volumes/chitty/github.com/CHITTYFOUNDATION/, /Volumes/chitty/github.com/CHITTYOS/, /Users/nb/desktop/projects/github.com/chittyapps/Volumes/chitty/temp/systems-registry-import-v3.csvPerform a comprehensive compliance check.
Run through the checklist directly:
(c as any) or other type-safety violationsFor detailed pass/fail criteria, consult references/compliance-checklist.md.
Dispatch specialized agents in parallel using Task with run_in_background: true:
| Agent | Checks |
|---|---|
chittycanon-code-cardinal | URI scheme, frontmatter, naming, ontology |
chittyagent-neon-schema | Schema drift, cross-service compatibility |
chittyregister-compliance-sergeant | Registration readiness, payload validation |
chittyconnect-concierge | Credentials, auth patterns, integrations |
Perform the quick audit inline while agents run. Aggregate all findings into a unified report using the format in references/compliance-checklist.md (Audit Report Format section).
Generate compliant files for a new ChittyOS service.
Before scaffolding, run Step 0 (Ecosystem Discovery) to:
Ask the user for:
{name}.chitty.cc)Generate files using templates from references/templates.md: CHARTER.md, CHITTY.md, health endpoint, wrangler config, and registration JSON. Populate dependency and integration sections from ecosystem discovery, not from guesswork. After scaffolding, run an audit to verify compliance.
Check live deployed services.
curl -s https://{service}.chitty.cc/health --max-time 5 | jq .
for svc in id auth connect api registry schema mcp finance command; do
echo -n "$svc: "
curl -s "https://$svc.chitty.cc/health" --max-time 5 | jq -r '.status // "DOWN"'
done
Compare deployed state against source: verify /health response format, check CHARTER.md tier consistency, verify wrangler compatibility date freshness.
Evaluate any artifact against ChittyOS certification criteria and award badges.
ChittyCertify operates like SOX/SOC II compliance auditing — it awards progressive certifications (NOT certificates; certificates are ChittyCert's domain).
[No Badge] → ChittyOS Compatible → Chitty Compliant → ChittyCertified → ChittyCanonical
Each level is cumulative. For full badge criteria, certification process, and report format, consult references/certification-criteria.md.
| Service | Role | What It Owns |
|---|---|---|
| ChittyGov | Business governance & compliance | Required reports, state filings, regulatory compliance, business guidelines, legal requirements. Defines what "compliant" means. Approves Canonical status. |
| ChittyCertify | Compliance certification (like SOX/SOC II) | Audits services against compliance standards, awards certification badges (Compatible/Compliant/Certified/Canonical), issues compliance certifications + JWT attestation tokens. Certifications, NOT certificates. |
| ChittyCert | Certificate Authority (CA) | PKI infrastructure, X.509 certificates, OCSP revocation, JWKS key registry, evidence authentication. Certificates, NOT certifications. |
| ChittyRegister | Registration authority | Service onboarding, compliance gatekeeper, validates before ecosystem entry. Register, NOT registry. |
| ChittyRegistry | Discoverable service registry | Searchable catalog of all registered services, tools, scripts, agents, and artifacts. Services are discovered here. Registry, NOT register. |
| ChittyCanon | Canonical authority | Entity type ontology (P/L/T/E/A), URI namespace, code pattern governance |
Consult these for detailed information:
references/compliance-checklist.md — Detailed pass/fail criteria for every compliance check, plus audit report formatreferences/certification-criteria.md — Full badge award criteria, certification process, artifact types, and certification report formatreferences/templates.md — Complete templates for scaffold mode (CHARTER.md, CHITTY.md, health endpoint, wrangler config, registration JSON, env types)| Skill | When to Chain |
|---|---|
wrangler-audit | After audit finds wrangler issues |
chitty-health | During monitor mode for live checks |
chitty-deploy | After scaffold + audit confirms compliance |
chitty-registry | After certification to register the service |