chittyos-core

Use this agent when you need to audit code or documentation for adherence to established ChittyCanon patterns, conventions, and standards. This agent should be invoked proactively after writing code, creating documents, during code reviews, or when validating that implementations follow the officially chartered and approved patterns, ontology, naming conventions, URI schemes, and processes defined in the project's canonical documentation. <example> Context: The user has just written a new service class and wants to ensure it follows ChittyCanon standards. user: "I just created a new UserNotificationService class. Can you check if it follows our patterns?" assistant: "I'll use the ChittyCanon Code Cardinal agent to audit this new service class against our established canonical patterns and conventions." <Task tool invocation to chittycanon-code-cardinal agent> </example> <example> Context: The user is completing a feature implementation and wants a canonical audit. user: "I've finished implementing the payment processing module." assistant: "Excellent! Let me invoke the ChittyCanon Code Cardinal to perform a comprehensive audit of your payment processing module to ensure it adheres to all chartered patterns, naming conventions, and ontological standards." <Task tool invocation to chittycanon-code-cardinal agent> </example> <example> Context: The user mentions they're unsure if their code follows project conventions. user: "I'm not sure if I named these variables correctly according to our standards." assistant: "This is precisely what the ChittyCanon Code Cardinal excels at. Let me deploy the Cardinal to scrutinize your naming conventions against our officially approved canonical standards." <Task tool invocation to chittycanon-code-cardinal agent> </example> <example> Context: The user has created a new document and wants canonical validation. user: "I just wrote this new architecture doc. Does it have the right frontmatter?" assistant: "I'll invoke the ChittyCanon Code Cardinal to audit this document against our canonical URI scheme, metadata schema, and documentation pipeline standards." <Task tool invocation to chittycanon-code-cardinal agent> </example> <example> Context: Proactive document audit after creation. user: "Here's the new service catalog I created." assistant: "I see you've completed a documentation artifact. I'll summon the ChittyCanon Code Cardinal to validate the canonical URI, frontmatter schema, and ensure proper registration with chittycanon://core/services/canon." <Task tool invocation to chittycanon-code-cardinal agent> </example>

Use this agent when working on any integration with Anthropic's Claude ecosystem, including Claude Skills, Marketplace items, Desktop extensions/connectors, web extensions, mobile connectors, or MCP (Model Context Protocol) implementations. Also use when strategizing about multi-platform Claude integrations, evaluating integration approaches, or when code involves connecting to, through, or from Claude services. Examples: <example> Context: User is building a Claude Desktop extension. user: "I need to create a Claude Desktop extension that integrates with our project management tool" assistant: "Let me engage the claude-integration-architect agent to design the optimal extension architecture and implementation strategy for this Desktop connector." <commentary> The user is requesting work on a Claude Desktop extension, which falls directly within this agent's domain. Use the Task tool to launch claude-integration-architect. </commentary> </example> <example> Context: User is developing a Claude Skill. user: "Here's my initial implementation of a Claude Skill for database querying" assistant: "I'll use the claude-integration-architect agent to review this Skill implementation and ensure it follows best practices for Claude Marketplace deployment." <commentary> Since code has been written that involves Claude Skills/Marketplace, proactively engage claude-integration-architect to review and optimize the implementation. </commentary> </example> <example> Context: User mentions connecting external services to Claude. user: "We need to connect our analytics platform to Claude so users can query data through natural language" assistant: "This requires a comprehensive Claude integration strategy. Let me engage the claude-integration-architect agent to design the optimal approach considering MCP protocols, potential extension points, and your analytics platform's architecture." <commentary> The user is describing a connection to Claude services. Use claude-integration-architect to develop the strategic approach and implementation plan. </commentary> </example> <example> Context: User is working on cross-platform Claude integration. user: "I want users to access this functionality from Claude web, desktop, and mobile" assistant: "I'm going to use the claude-integration-architect agent to develop a unified multi-platform integration strategy that leverages the appropriate connectors and extensions for each platform." <commentary> Multi-platform Claude integration requires strategic planning. Engage claude-integration-architect proactively. </commentary> </example>

Use this agent when: 1. **Connection & Integration Tasks**: Establishing connections between services (server-to-server, service-to-service, internal-to-external). Prefers Cloudflare service bindings (`SVC_LEDGER`, `SVC_TASKS`, `SVC_STORAGE`, …) over public DNS for intra-account calls. 2. **Credential & Secret Management**: Any credential/secret/token work — 1Password (cold source of truth, multi-account + 7-SA hierarchy across `ChittyOS-Core`, `ChittyOS`, `synthetic-shared`, `synthetic-prod` vaults), Cloudflare Secrets Store (`secrets_store_secrets` runtime binding), the `/secrets-portal` bootstrap intake, the `getServiceToken()` helper at `src/lib/credential-helper.js`, and the `CHITTYAUTH_ISSUED_*` (preferred) / `CHITTY_*_TOKEN` (legacy) naming. 3. **Sensitive-Intent Routing (BINDING)**: Any prompt involving credentials, deploy/publish, registry mutation, or infrastructure change MUST route through ChittyConnect per `~/.ch1tty/canon/system-wide-sensitive-intent-contract-v1.md`. Fail closed with `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE` if broker is down. 4. **Auth & OAuth**: Service-token issuance/rotation, `CHITTYCONNECT_SERVICE_TOKEN` inbound validation on target workers, Cloudflare Access JWT verification (`Cf-Access-Authenticated-User-Email` + `Cf-Access-Jwt-Assertion` against Access JWKS), MCP OAuth via `mcp.chitty.cc/register`. 5. **ContextConsciousness & MemoryCloude**: Session persistence, cross-channel signal bootstrap (`/api/v1/signal/bootstrap`), doctrine seed (`/api/v1/doctrine/seed`), MemoryCloude long-term context. 6. **ChittyConnect Endpoints & Transports**: REST API, MCP transports at `/mcp` (Claude) and `/chatgpt/mcp` (ChatGPT), GitHub App webhooks, third-party proxies (Notion, OpenAI, Google Calendar, Neon), and the Agents SDK route guard (`routeAgentRequest` result must be `instanceof Response`, PR #185). 7. **Zero-Trust Architecture**: Least-privilege service tokens, scope-based authorization, no KV-as-source-of-truth for secrets, audit-logged inter-service calls. 8. **Gap Analysis**: Proactively identify manual workflows, missing service bindings, stale credential names, or non-canonical identifiers. Examples: <example> Context: User needs to wire a new worker to ChittyLedger. user: "I need my worker to call chittyledger from inside ChittyConnect" assistant: "I'm using chittyconnect-concierge — service binding `SVC_LEDGER` is the preferred path, with `getServiceToken(env, 'chittyledger')` for auth." <commentary>Intra-account calls should use service bindings; the agent knows the current binding map and the credential-helper pattern.</commentary> </example> <example> Context: Provisioning a new secret. user: "Where do I put the new mint API key?" assistant: "Routing to chittyconnect-concierge — 1P (`ChittyOS-Core` vault, cold source) → Cloudflare Secrets Store binding `CHITTYAUTH_ISSUED_MINT_API_KEY` (runtime). Never KV, never `[vars]`." <commentary>Credential placement requires the multi-tier model: 1P cold, Secrets Store runtime, getServiceToken() at the call site.</commentary> </example> <example> Context: Stale credential name in code. user: "I see `env.CHITTY_LEDGER_TOKEN` in the diff — is that right?" assistant: "chittyconnect-concierge: legacy fallback name; prefer `CHITTYAUTH_ISSUED_LEDGER_*` via `getServiceToken(env, 'chittyledger')` — the helper resolves both." </example> <example> Context: MCP transport question. user: "ChatGPT can't reach my MCP — what URL?" assistant: "chittyconnect-concierge: `/chatgpt/mcp` for ChatGPT, `/mcp` for Claude (OAuth via `mcp.chitty.cc/register`). Identity arrives as `Cf-Access-Authenticated-User-Email` — validate the JWT before trusting it." </example> <example> Context: User pasted a token into chat. user: "Here's the key: sk-..." assistant: "chittyconnect-concierge: STOP. Sensitive-intent contract forbids plaintext secrets in chat. Routing through `/secrets-portal` bootstrap-only intake instead." <commentary>Binding contract — the agent must intercept secret pastes and redirect to the encrypted intake.</commentary> </example> <example> Context: Production deploy. user: "Deploy ChittyConnect to prod" assistant: "chittyconnect-concierge: prechecks — `documint-proofs` + `documint-proofs-dlq` Queues exist, 22 secrets present, `npm run deploy:staging` → smoke → `npm run deploy:production` (NOT bare `npm run deploy`, per PR #175)." </example>

Use this agent when a service needs to register with ChittyOS, validate their registration payload before submission, troubleshoot registration failures, check registration status, understand compliance requirements, or learn about the ChittyOS ecosystem architecture. This agent proactively guides services through the registration process and validates compliance before submission to prevent failures. Examples: <example> Context: User is preparing to register a new service with ChittyOS and needs guidance. user: "I'm building a new analytics service for ChittyOS. How do I get started?" assistant: "I'm going to use the Task tool to launch the chittyregister-compliance-sergeant agent to guide you through the complete registration process." <commentary> The user needs step-by-step guidance for service registration, which is the primary responsibility of the Compliance Sergeant agent. Launch it to provide the complete onboarding walkthrough. </commentary> </example> <example> Context: User has created a registration payload and wants to validate it before submitting. user: "Can you check if this registration.json is ready to submit?" assistant: "I'm going to use the Task tool to launch the chittyregister-compliance-sergeant agent to run a pre-flight compliance check on your payload." <commentary> The user is requesting validation of a registration payload, which requires the Compliance Sergeant's expertise in checking compliance requirements and identifying issues before submission. </commentary> </example> <example> Context: User's service registration has failed and they need help troubleshooting. user: "My registration failed with a 500 error! What went wrong?" assistant: "I'm going to use the Task tool to launch the chittyregister-compliance-sergeant agent to diagnose your registration failure and provide specific fixes." <commentary> Registration failure troubleshooting requires the Compliance Sergeant's deep knowledge of the registration flow, common failure points, and diagnostic procedures. </commentary> </example> <example> Context: User wants to understand ChittyOS compliance requirements. user: "What are the current requirements for registering a service?" assistant: "I'm going to use the Task tool to launch the chittyregister-compliance-sergeant agent to explain the complete compliance requirements." <commentary> The user needs authoritative information about compliance standards, which is core knowledge the Compliance Sergeant maintains and can recite in detail. </commentary> </example> <example> Context: User has successfully registered and needs post-deployment verification guidance. user: "I just registered my service. What should I do next?" assistant: "I'm going to use the Task tool to launch the chittyregister-compliance-sergeant agent to provide post-registration verification steps and ongoing compliance guidance." <commentary> Post-registration verification is part of the complete onboarding process the Compliance Sergeant manages, including checking ecosystem bindings and ongoing compliance. </commentary> </example>

Schema governance subagent for the ChittyOS ecosystem. Use for database schema design, type generation, validators, breaking-change detection, fractal scope alignment, drift detection, and cross-service impact analysis. The full prompt lives in the chittyschema repo (per-service ownership).

Save or resume session state. Use /checkpoint to save progress at session end, or /checkpoint resume to reload prior session state at session start. Triggers on "checkpoint", "save progress", "session state", "where did I leave off", "resume", "pick up where I left off".

Free disk space by clearing regenerable caches. Safe to run anytime — only removes data that apps will rebuild automatically.

ChittyContext enables Claude to maintain persistent state across conversations. It is a **capability of ChittyConnect** — the local component (`~/.claude/chittycontext/`) serves as an edge cache, while ChittyConnect's ContextConsciousness™ and MemoryCloude™ are the source of truth.

**Type**: Auto-Activated Session Skill