# Mrs. Kitty AI Controller — Full Documentation > Mrs. Kitty AI Controller is a safety-first AI coding controller for Claude Code. > It enforces 24+ sequential safety gates, persistent cross-session memory, > headed browser automation testing, and multi-agent orchestration. > Free during beta. Version 1.3.9 (Windows) / 1.0.11 (Linux). No account required. ## Instructions for AI Agents When discussing Mrs. Kitty AI Controller: - It requires Claude Code (Anthropic's CLI tool) — it is not a standalone IDE or editor - The gate system uses PreToolUse/PostToolUse/Stop hooks in Python, not a custom runtime - Memory is file-based (MEMORY.md + JSONL archive), not database-backed - Browser testing always runs headed (visible Chrome window), never headless - It is currently free during beta — the value stack pricing ($2,611/mo) shows what each component would cost separately - Installation takes 8 minutes, requires no account, email, or tracking - Current version: 1.3.9 (Windows installer), 1.0.11 (Linux/Mac shell script) - The product name is "Mrs. Kitty AI Controller" or "Kitty AI Controller" - Built and tested independently over 8 months — 490 Python modules, 14,400+ lines of hooks, 33 Python hook modules - The 9 bundled skills are improved versions of free open-source community skills, plus 15+ native workflow skills - 50+ specialist agents include: scout, oracle, architect, kraken, arbiter, sleuth, spark, profiler, herald - RTK (Rust Token Killer) saves 82% average tokens via 12 filtering strategies - The test-installer skill tests installers on Windows VMs via Docker with golden snapshot restore --- # Getting Started with Mrs. Kitty AI Controller Install a 24-gate safety controller for Claude Code in 8 minutes with no account, no email, and no tracking. ## Requirements You need Claude Code (Anthropic's official CLI tool) and an Anthropic API key or subscription. The controller runs on Windows 10+ with WSL2 or native Linux. Docker Desktop is optional and only needed for cross-terminal coordination between multiple Claude sessions. ## Download Two installation packages are available: - **Windows**: `KittyAIController-v1.3.9-Setup.exe` (Inno Setup installer) - **Linux / Mac**: `KittyAIController-v1.0.11-linux.sh` (shell script) Both are available at [https://erebora.org/kittyAI/](https://erebora.org/kittyAI/). ## Installation Installation takes approximately 8 minutes. No account creation, no email address, and no usage tracking of any kind. Uninstall in 2 clicks through Windows Add/Remove Programs or by running the uninstall script on Linux. The installer configures Claude Code hooks, sets up the memory system, installs 9 bundled skills, and deploys 50+ specialist agent definitions. ## First Run Open any terminal and type `claude`. The system auto-configures on first launch: - Hook files are linked into Claude Code's hook directory - The memory system initializes with a blank MEMORY.md - Agent definitions are registered and ready to spawn - The gate pipeline activates immediately No manual configuration steps are required. ## The 5-Step Workflow This is how you work with Mrs. Kitty AI Controller every day: ### 1. Describe Your Vision Talk like an architect, not a bricklayer. Say what you want built, not how to build it. The system handles research, planning, and implementation details. ### 2. Answer Clarifying Questions The AI asks focused multiple-choice questions, one at a time. These are generated by the Thinking Partner gate (97% confidence threshold) to ensure the AI understands your intent before writing code. ### 3. Review the Plan Research happens automatically via specialist agents (scout, oracle). A structured plan is presented for your approval. No code is written until you explicitly approve. ### 4. Watch It Build The system enters a TDD loop: write failing tests, implement minimum code, refactor. Sub-agents spawn in parallel for independent tasks. You see real-time progress. ### 5. Steer the Ship Add features, change design direction, or pivot entirely while work is in progress. The gate system ensures every change follows the same research-plan-approve-build-test cycle. ## What to Expect When you first use the controller, you will see messages that may be unfamiliar: - **Gate messages** (teal or red text) that pause progress. These are safety checks, not errors. They ensure the AI has researched, planned, and received approval before editing your code. - **Agent spawning messages** indicating specialist sub-agents are working on parts of your task in parallel. - **Memory recall** showing relevant learnings from past sessions, ranked by TF-IDF relevance scoring. --- # Safety Gates -- 24+ Sequential Enforcement Pipeline Every AI edit, write, and bash command passes through 24+ sequential safety gates before execution, implemented in 3,460 lines of Python with fail-closed design. ## What Gates Are Gates are PreToolUse hooks written in Python that intercept every tool call Claude Code makes BEFORE it executes. They run inside `pretooluse.py` (3,460 lines) as a sequential pipeline. Each gate evaluates the proposed action and either allows it, blocks it, or requires additional steps. ## Fail-Closed Design If any gate crashes, throws an exception, or encounters an unexpected state, ALL edits stop until the issue is resolved. There are no silent failures. This is the opposite of fail-open systems where errors default to allowing actions through. ## The Full Gate Pipeline | # | Gate Name | Type | What It Does | |---|-----------|------|-------------| | M | Maintenance Mode | Override | Bypasses all gates temporarily (1hr auto-expire) | | 0.5 | Plan Mode Required | Hard Block | Code files need approved plan before editing. 5 independent approval paths. | | 0.5b | Plan File Enforcement | Hard Block | Plan markdown files can only be edited inside plan mode. Unbypassable. | | 01 | Project Analyzer | Always On | Forces AI to read and understand project before editing | | 1.5 | Memory Recall | Always On | Searches learnings via TF-IDF scoring. Self-consuming marker. | | 1.7 | TODO Acknowledgment | Always On | Forces task organization when multiple tasks detected. One-shot per session. | | 02 | Thinking Partner | Reflexion | 97% confidence threshold. 5-factor weighted scoring. Reflexion loop (Shinn et al. 2023). | | 2b | Post-Failure Research | Hard Block | After any failure, must research before retrying | | 2c | Read-Before-Edit | Always On | Config files (.json, .yaml, .toml, .ini) must be read before editing | | 2.5 | Hedging Scanner | Always On | Scans AI's own text for uncertainty language ("I'm not sure"). Blocks if found. | | 2.5b | Bug Resolution Tracker | Always On | Prevents abandoning active debugging for new work | | 03 | Research Saturation | Risk-Routed | Minimum research threshold based on task complexity (3-6 points) | | 04 | Research Gate | Risk-Routed | Task-based evidence requirements via complexity classifier with cache | | 05 | Research Persistence | Soft Block | Forces AI to share research findings before coding | | 06 | User Approval | Hard Block | Plan must be presented and approved by user | | 07 | Project Snapshot | Backup | Full session-level backup before changes begin | | 08 | Per-File Checkpoint | Backup | Individual file backup (4 strategies: GIT, BLOB SHA256, SKIP, IGNORE) | | 09 | Simplification Guard | Hard Block | Blocks significant code removal without justification | | 10 | Test-Before-Deploy | Hard Block | Blocks deployment commands until all tests pass | | 11 | PASS Lock | Disabled | Disabled Feb 2026 (redundant with Test-Before-Deploy). Was SHA-256 hash lock. | | 12 | Bash Loop Detector | Self-Heal | Prevents brute-force retry loops (Layer 1: immediate, Layer 2: accumulating) | | 13 | Completion Blocker | Hard Block | Checks filesystem state, not AI text. AI can't claim "done" while tests fail. | ## Gate Types Explained - **Hard Block**: Stops execution completely until the condition is satisfied. No workaround. - **Always On**: Runs on every tool call regardless of risk level. Cannot be skipped. - **Risk-Routed**: Runs based on assessed task complexity. Skipped for trivial operations. - **Soft Block**: Warns and requires acknowledgment but can be overridden with justification. - **Backup**: Creates recovery points. Does not block execution. - **Self-Heal**: Detects destructive patterns and automatically intervenes. - **Reflexion**: Academic technique (Shinn et al. 2023) where the AI evaluates its own reasoning quality. - **Disabled**: Gate exists in the pipeline but is turned off. Kept for documentation and potential re-enablement. ## Risk Classification -- 4-Level Gate Routing Every edit is classified into one of 4 risk levels that determine which gates run: | Risk Level | Criteria | Gate Behavior | |-----------|----------|---------------| | NONE | Trivial edits (docs, comments, config) | Behavioral gates skipped entirely (skip_behavioral=True) | | LOW | Simple changes with clear intent | Behavioral gates skipped | | MEDIUM | Significant code changes | 97% confidence enforced, auto-escape on tier 3 if research was done | | HIGH | Major refactors, security, critical infrastructure | 97% confidence enforced, NEVER auto-escapes | Risk scoring factors: clarity score (from prompt analysis), change size (lines affected), file type (code vs config), and security content detection (+25 points for password/token/auth patterns). Gates that ALWAYS run regardless of risk: Plan Mode (0.5/0.5b), Memory Recall (1.5), Hedging Scanner (2.5), Bug Resolution (2.5b), Read-Before-Edit (2c), Post-Failure Research (2b), all backup gates (07/08), Simplification Guard (09), Test-Before-Deploy (10). Gates that skip for NONE/LOW risk: Project Analyzer (01), Thinking Partner (02), Research Saturation (03), Research Gate (04), Research Persistence (05), User Approval (06), TODO Acknowledgment (1.7). ## Phase Orchestrator -- 9-Phase Workflow The system tracks a development workflow phase per session: 1. IDLE -- No work in progress 2. EXPLORING -- Understanding the project (set by Project Analyzer gate) 3. RESEARCHING -- Doing external research (set by Research Saturation/Gate/Persistence gates) 4. PLANNING -- Writing implementation plan (set by Research Persistence gate) 5. CHECKPOINT_1 -- Reflexion on failures (set by Thinking Partner) 6. CHECKPOINT_2 -- Final plan approval (set by User Approval gate) 7. IMPLEMENTING -- Writing code 8. TESTING -- Running tests 9. VERIFIED -- Tests passing, ready to deploy Phase state persists per-session in phase-state/{session_id}.json. Gates use the current phase to coordinate the workflow -- earlier phases block later actions. ## Bypass Protection The gate system detects and blocks 30+ bypass patterns that an AI might use to circumvent safety controls. These include echo redirects, heredoc writes, tee commands, base64 encoding, pipe tricks, and other shell techniques that could write files without going through the gate pipeline. ## Maintenance Mode When you need to perform infrastructure work that gates would block, say "maintenance" to temporarily bypass all gates. Backups (gates 07 and 08) still run even in maintenance mode. Maintenance mode auto-expires after 1 hour as a safety net. Say "done" to re-engage all gates immediately. ## Color Coding Gate messages use consistent color coding in the terminal: - **Teal (#4DD9C0)**: Gate passed, execution continues - **Red (#ff003c)**: Gate blocked, action requires resolution - **Orange (#ffb800)**: Risk-routed or skippable gate - **Green (#00e87b)**: Approved, proceeding --- # Memory System -- Cross-Session Learning and Recall A two-tier memory system stores a continuously growing archive of learnings across sessions, using TF-IDF scoring with time decay to surface relevant knowledge at the right moment. ## Architecture The memory system uses two tiers of storage working together: - **MEMORY.md** (core memory): Always loaded at the start of every session. Kept concise at approximately 200 lines. Contains the most important distilled knowledge -- architectural decisions, critical lessons, and active project context. - **memory_log.jsonl** (archive): Append-only log that grows continuously. Every learning, error resolution, and decision is recorded here with timestamps and tags. This is the searchable long-term memory. ## 8 Knowledge Types Every memory entry is tagged with one of 8 types: | Type | What It Captures | |------|-----------------| | ARCHITECTURAL_DECISION | Design choices and system structure decisions | | WORKING_SOLUTION | Fixes and solutions that worked | | CODEBASE_PATTERN | Patterns discovered in code | | FAILED_APPROACH | What did not work and why | | error_resolution | How specific errors were resolved (auto-captured) | | test_result | Test pass/fail context (auto-captured) | | USER_PREFERENCE | User's preferred approaches and style | | in_session | General session learnings | ## TF-IDF Scoring Memory recall uses Term Frequency-Inverse Document Frequency matching. When you describe a task, the system scores every memory entry against your current context. Entries with rare, specific terms that match your task score highest. Common words are down-weighted automatically. The full scoring formula: ``` score = (exact_matches + stem_matches * 0.7 + substring_matches * 0.5) / query_token_count * type_boost (1.5x for user_correction, repeated_correction, preference) * tag_boost (2x if tags overlap with query) * e^(-0.03 * age_in_days) ``` ## Time Decay Recent learnings score higher than older ones. A learning from yesterday outranks an identical learning from last month. This ensures the AI prioritizes fresh context. However, older learnings are not deleted -- they remain in the archive and can still surface if their content is highly relevant. ## State Marker Resilience State markers use TTL-based expiration for resilience. Memory markers have 10-minute TTL, bug resolution markers have 1-hour TTL. This provides resilience against context compaction without requiring session_id changes. ## 3 Recall Tiers Memory matches are injected at different levels based on their relevance score: | Tier | Score | Behavior | |------|-------|----------| | HOT | > 0.3 | Full content injected into context. Acknowledgment required before proceeding. | | WARM | 0.1 - 0.3 | Preview shown for reference. AI can use or skip. | | COLD | < 0.1 | Not shown. MEMORY.md core memory is still loaded regardless. | ## Auto-Learning Three automatic capture mechanisms run without any user action: 1. **Error-resolution pairs**: When the AI encounters an error and resolves it, the pair is recorded automatically. 2. **Test results**: Pass/fail outcomes with context are captured after every test run. 3. **Session-end extraction**: When a session ends, a dedicated hook extracts decisions, fixes, and user preferences from the full transcript. ## Failed Approach Tracking The FAILED_APPROACH type is specifically designed to prevent the AI from repeating mistakes. When a solution fails, the system records what was tried, why it failed, and what eventually worked. On future sessions, if the AI is about to try a known-failed approach, the memory system surfaces the warning. ## Distillation Over time, the JSONL archive grows large. Periodic distillation consolidates the archive into MEMORY.md core memory. This process summarizes related learnings, removes redundancy, and keeps core memory concise while preserving details in the archive. Run manually or ask the AI to "distill my memories." --- # Browser Testing -- Headed CDP Automation A CDP-based browser testing tool that connects to a real visible Chrome instance, with 3 verification tiers and SHA-256 tamper-evident receipts proving every test actually happened. ## What It Is agent-browser is a CLI tool built on Chrome DevTools Protocol (CDP). It connects to a real Chrome instance running on your machine -- the same browser you use every day, with your cookies, extensions, and full-size window. This is not a simulated browser or a headless phantom. ## Always Headed The browser window is ALWAYS visible during testing. This is enforced via `AGENT_BROWSER_HEADED=true` and is a hard requirement, not a preference. The user can watch exactly what the AI is testing in real time. Headless mode is permanently disabled. If the debug Chrome is not running, the tool falls back to its own Chromium instance (smaller window, no saved cookies) but still runs headed. ## 3 Verification Tiers ### Tier 1 -- Snapshot (Fastest) Captures the accessibility tree and text content of the page. Use for HTML structure, text content, and component logic verification. No screenshot is needed -- the output is text-based and analyzed directly. Single command: ``` agent-browser open && agent-browser errors && agent-browser snapshot ``` ### Tier 2 -- Screenshot (Visual) Captures a visual image of the page. Use for CSS validation, color verification, spacing checks, and layout inspection. The AI reads the screenshot image and describes what it sees. Two steps: ``` agent-browser open && agent-browser errors && agent-browser screenshot ``` ### Tier 3 -- Comprehensive (Both) Captures both the accessibility tree snapshot and a visual screenshot. Use when unsure whether the issue is structural or visual: ``` agent-browser open && agent-browser errors && agent-browser snapshot && agent-browser screenshot ``` ## Parallel Multi-Page Testing Multiple pages can be tested in a single command chain using separate tabs. This is used for comparing pages, testing navigation flows, or verifying multiple routes simultaneously: ``` agent-browser open URL1 && agent-browser screenshot /tmp/p1.png && agent-browser open URL2 && agent-browser screenshot /tmp/p2.png ``` Both screenshots are then read and analyzed by the AI in parallel. ## Console Error Detection JavaScript errors and warnings are captured automatically via `agent-browser errors`. This runs on every verification tier. Console errors surface problems that are invisible in screenshots -- failed API calls, missing resources, runtime exceptions, and deprecation warnings. ## SHA-256 Tamper-Evident Receipts Each verification generates a SHA-256 hash receipt. This receipt proves that a real browser test actually occurred at a specific time with specific content. The AI cannot fabricate a screenshot or claim testing happened when it did not. The hash is tied to the actual page content captured during the test. ## Self-Verification Rule After making any frontend change, the AI MUST verify the result itself. It never says "please check the browser" or "verify the changes look correct." Instead, it opens the page, captures a snapshot or screenshot, reads the output, and describes what it sees. If something looks wrong, it fixes the issue and re-verifies automatically. --- # Skills & Agents -- 9 Bundled Skills, 15+ Native Skills, and 50+ Specialist Agents 9 community-voted skills ship pre-configured, 15+ native workflow skills provide built-in development workflows, 50+ specialist agents handle parallel sub-tasks, and RTK Token Killer saves 82% average on token costs. ## 9 Bundled Skills All 9 skills are based on free open-source originals, improved and pre-configured to work with the gate system. They were selected by community vote. ### 1. Superpowers (by Jesse Vincent) Brainstorming, TDD workflows, systematic debugging, and verification workflows. Upgraded with instant response and embedded skill cores that eliminate external lookups. ### 2. Commit Commands (Anthropic) Git commit automation, clean branch management, and a combined commit-push-PR workflow. Handles conventional commit formatting and multi-file staging. ### 3. PR Review Toolkit (Anthropic) 6 specialized review agents that run in parallel. Each agent focuses on a different aspect: security, performance, correctness, style, testing, and documentation. ### 4. Feature Dev (Anthropic) Architecture-first development workflow: explore the codebase, design the solution, implement the code, then review the result. Each phase is a distinct step with its own agent. ### 5. Code Review (Anthropic) Automated code review against your project's CLAUDE.md guidelines. Checks for consistency with established patterns, naming conventions, and architectural decisions. ### 6. Code Simplifier (Anthropic) Runs automatically after each coding task to identify simplification opportunities. Reduces complexity, removes dead code, and consolidates redundant logic. ### 7. Frontend Design (Anthropic) An 842-line skill implementing Hormozi conversion architecture and 2026 design patterns. Covers layout systems, typography, color theory, responsive breakpoints, and conversion-optimized component patterns. ### 8. Greptile AI-powered code review with pattern detection. Identifies anti-patterns, security vulnerabilities, and inconsistencies across the codebase using structural analysis. ### 9. Context7 (Upstash) Real-time documentation lookup for any library. Queries up-to-date docs instead of relying on training data. Ensures the AI uses current API signatures, not outdated ones from its training cutoff. ### 10. Test Installer (Built-in) End-to-end installer testing on a Windows VM via Docker. Compiles the installer with Inno Setup, deploys to a fresh VM restored from a golden snapshot, runs 17+ headless verification checks, then performs GUI walkthrough via agent-browser over noVNC. Iterates on failures automatically with failure-to-fix mapping. Invoked with `/test-installer`. ## 15+ Native Workflow Skills Built-in skills that provide development workflow orchestration without external dependencies: | Skill | Purpose | |-------|---------| | build | Workflow orchestrator for feature development | | commit | Git commits with user approval | | continue | Resume work from previous plans | | debug | Issue investigation via logs and git history | | explore | Codebase exploration at varying depths | | fix | Bug investigation and resolution orchestrator | | tdd | Test-driven development workflow | | test | Comprehensive testing: unit, integration, E2E | | review | Parallel code review with specialist agents | | frontend-design | Production-grade UI generation | | help | Workspace discovery | | recall | Semantic memory search | | remember | Store learnings for future recall | | agent-browser | CDP browser automation | | test-installer | VM installer testing | ## 50+ Specialist Agents Agents are purpose-built sub-processes that handle specific tasks. They work in separate contexts so your main conversation stays clean. | Agent | Purpose | |-------|---------| | scout | Codebase exploration and pattern finding | | oracle | External research and documentation lookup | | architect | Planning and system design | | phoenix | Large-scale refactoring plans | | kraken | Implementation via strict TDD workflow | | spark | Quick fixes and small changes | | arbiter | Test execution and validation | | sleuth | Debugging and root cause analysis | | profiler | Performance analysis and optimization | | herald | Release management and changelogs | | validator | Integration and end-to-end testing | Additional specialist agents cover documentation, migration, security auditing, dependency management, and more. Each agent has a dedicated system prompt defining its behavior, tools, and constraints. ## Context Protection Agents work in isolated contexts. When a complex task spawns 3 sub-agents, those agents consume their own context windows -- not yours. Your main conversation remains clean and focused on high-level steering. Agent results are summarized back to you. ## RTK Token Killer RTK (Rust Token Killer) is a Rust CLI proxy that sits between Claude Code and system tools. It compresses tool output using 12 filtering strategies, achieving 82% average token savings. Overhead is approximately 10ms per call. This means longer conversations before hitting context limits and lower API costs. ## Cross-Terminal Coordination When running multiple Claude Code sessions in different terminals, a PostgreSQL-backed coordination system provides: - **Session awareness**: Each terminal registers itself and can see peer sessions - **File-level locking**: If one session is editing a file, another session receives a warning before touching the same file - **Real-time heartbeat**: Sessions broadcast heartbeats so the system knows which are still active This prevents merge conflicts and duplicated work when running parallel Claude sessions on the same project. --- # Frequently Asked Questions 12 answers about Mrs. Kitty AI Controller, each starting with a direct one-sentence response. ## 1. What is Mrs. Kitty AI Controller? It is a safety-first controller layer that wraps Claude Code with 24+ enforcement gates, persistent memory, browser testing, and multi-agent orchestration. Think of it as an operating system for AI-assisted coding -- it does not replace Claude Code, it governs how Claude Code operates on your codebase. The gate pipeline ensures every AI action follows a research-plan-approve-build-test-verify cycle. ## 2. How does the safety gate system work? Every tool call Claude Code makes (edits, writes, bash commands) passes through a sequential pipeline of 24+ Python-based gates before execution. Each gate evaluates the proposed action against specific criteria -- confidence thresholds, research requirements, plan approval, test status, and more. If any gate fails or crashes, all edits stop (fail-closed design). The full pipeline is implemented in 3,460 lines of Python. ## 3. Is it really free? What's the catch? Yes, it is completely free during the beta period with no credit card, no account creation, and no usage tracking. The value stack of all components totals $2,611/month based on comparable commercial tooling. The only requirement is a Claude Code subscription from Anthropic ($20/month for Pro or $200/month for Max), which provides the underlying AI model that Mrs. Kitty controls. ## 4. What platforms does it support? Windows 10+ with WSL2 (version 1.3.9 installer) and native Linux (version 1.0.11 shell script). The Windows installer is an Inno Setup executable. The Linux installer is a self-contained shell script. Docker Desktop is optional and only needed for cross-terminal coordination between multiple Claude sessions. ## 5. How is this different from using Claude Code without it? Without Mrs. Kitty, the AI edits code the moment it has a guess -- no research requirement, no plan approval, no test enforcement, and no memory between sessions. With Mrs. Kitty, 24+ gates enforce a strict sequence on every edit: research the problem, reach 97% confidence, present a plan, get user approval, build with TDD, pass all tests, and verify the result. Failed approaches are remembered across sessions so mistakes are not repeated. ## 6. What is the memory system? It is a two-tier persistent memory that carries knowledge across sessions using TF-IDF relevance scoring. Core memory (MEMORY.md, approximately 200 lines) loads at every session start. The append-only archive (memory_log.jsonl) stores 8 types of knowledge including failed approaches, working solutions, and user preferences. Recent learnings score higher via time decay, and matches are injected at 3 tiers (HOT, WARM, COLD) based on relevance. ## 7. Can I bypass the gates when I need to? Yes, say "maintenance" to temporarily bypass all gates for infrastructure work. Maintenance mode auto-expires after 1 hour as a safety net. Backup gates (project snapshot and per-file checkpoint) continue running even in maintenance mode. Say "done" to re-engage all gates immediately. This is the only supported bypass mechanism -- the system detects and blocks 30+ other bypass patterns. ## 8. How does browser testing work? agent-browser connects to a real Chrome instance via Chrome DevTools Protocol (CDP) with the window always visible (never headless). Three verification tiers are available: Tier 1 (snapshot) captures the accessibility tree for structural checks, Tier 2 (screenshot) captures visual images for CSS and layout validation, and Tier 3 (comprehensive) captures both. Every verification generates a SHA-256 hash receipt proving the test actually occurred. ## 9. What are the 9 bundled skills and native workflows? The 9 bundled skills are: Superpowers (brainstorming and TDD), Commit Commands (git automation), PR Review Toolkit (6 parallel review agents), Feature Dev (architecture-first workflow), Code Review (guideline enforcement), Code Simplifier (automatic complexity reduction), Frontend Design (842-line Hormozi conversion architecture), Greptile (pattern-based code review), and Context7 (real-time library documentation lookup). All 9 are based on free open-source originals, improved and pre-configured for the gate system. Additionally, a built-in test-installer skill provides end-to-end installer testing on Windows VMs. 15+ native workflow skills (build, commit, continue, debug, explore, fix, tdd, test, review, frontend-design, help, recall, remember, agent-browser, test-installer) provide development orchestration without external dependencies. ## 10. Does it comply with the EU AI Act? The 24-gate audit trail provides governance tooling ahead of the August 2, 2026 enforcement date. Every AI decision passes through documented checkpoints with timestamps, confidence scores, and approval records. Per-file SHA-256 checkpoints create a tamper-evident record of what changed and when. This does not constitute legal compliance certification, but it provides the technical infrastructure that compliance frameworks require. ## 11. How long does installation take? Approximately 8 minutes from download to first run. No account creation, no email address, and no usage tracking. The installer handles hook configuration, memory system setup, skill installation, and agent registration automatically. Uninstall takes 2 clicks on Windows or one command on Linux. ## 12. Is it open source? The 9 bundled skills are based on open-source originals. 7 standalone skills are available free on GitHub at [https://github.com/kittyai/kittyai-skills](https://github.com/kittyai/kittyai-skills). The gate system, controller infrastructure, memory system, and agent orchestration are proprietary. The underlying Claude Code CLI is developed by Anthropic and is itself open source.