Add Kilo Code output (#40)

Author: chubes4

README.md

@@ -2,7 +2,7 @@
 
 Shared source for WordPress-focused agent skills and plugin packaging.
 
-This repo currently packages shared skills and setup files for Amp, Cline, Codex, Claude Code, Cursor, Continue, Devin CLI, Factory Droid, GitHub Copilot, Gemini, Junie, Pi, Qodo, Roo Code, Windsurf/Cascade, Aider, and Zed as separate outputs:
+This repo currently packages shared skills and setup files for Amp, Cline, Codex, Claude Code, Cursor, Continue, Devin CLI, Factory Droid, GitHub Copilot, Gemini, Junie, Kilo Code, Pi, Qodo, Roo Code, Windsurf/Cascade, Aider, and Zed as separate outputs:
 
 - prefers the WordPress Studio MCP server for site management, screenshots, and block validation
 - falls back to the Studio CLI through a shared Studio skill when MCP is unavailable
@@ -16,6 +16,7 @@ This repo currently packages shared skills and setup files for Amp, Cline, Codex
 - includes an Aider config and conventions pack for terminal pair-programming
 - keeps skills shared so other surfaces can reuse them later
 - includes Continue-native setup files for WordPress.com rules, prompts, and MCP configuration
+- adds Kilo Code-native rules, skills, agent, AGENTS.md, plugin directory documentation, and project MCP config
 - includes Devin CLI project config, rules, and skills under Devin's documented `.devin/` surfaces
 - adds Cline workspace rules, skills, MCP settings, and Cline plugin-surface documentation from official Cline docs
 - adds a Pi skills package using Pi's official package manifest and Agent Skills support
@@ -150,6 +151,21 @@ claude --plugin-dir ./plugins/claude-code
    - running an audit request
 6. For workflow telemetry coverage, make sure the generated `wordpress-telemetry` MCP server starts alongside `wordpress-studio`.
 
+### Test in Kilo Code
+
+1. Install Kilo Code from the official docs: https://kilocode.ai/docs/getting-started/installing
+2. Open `./plugins/kilo-code` as the Kilo Code project root, or copy `kilo.jsonc`, `AGENTS.md`, and `.kilo/` into a target workspace root.
+3. Confirm the generated Kilo config exists at `plugins/kilo-code/kilo.jsonc`.
+4. Confirm the generated Kilo custom rule exists at `plugins/kilo-code/.kilo/rules/wordpress-com.md`.
+5. Confirm the shared skills exist under `plugins/kilo-code/.kilo/skills/`.
+6. In Kilo Code, confirm `wordpress-studio` and `wordpress-telemetry` are available in MCP settings.
+7. Try the same representative tasks:
+   - creating a new site
+   - building or editing a theme
+   - creating a custom block
+   - creating a custom plugin
+   - running an audit request
+
 ### Test in Junie
 
 1. Copy or open `./plugins/junie` as the Junie project root.
@@ -301,6 +317,7 @@ pi install ./plugins/pi
 - Roo Code workspace output in `plugins/roo-code/`
 - Cline workspace output in `plugins/cline/`
 - Gemini packaging output in `plugins/gemini/`
+- Kilo Code packaging output in `plugins/kilo-code/`
 - Junie packaging output in `plugins/junie/`
 - GitHub Copilot packaging output in `plugins/copilot/`
 - Qodo workspace output in `plugins/qodo/`
@@ -328,6 +345,7 @@ The build packages the shared skills into:
 - `plugins/gemini/skills/`
 - `plugins/junie/.junie/skills/`
 - `plugins/copilot/skills/`
+- `plugins/kilo-code/.kilo/skills/`
 - `plugins/qodo/skills/`
 - `plugins/zed/.agents/skills/`
 - `plugins/windsurf/skills/`
@@ -349,6 +367,7 @@ It also generates plugin-specific MCP configs or setup guidance for each surface
 - Gemini: `plugins/gemini/.gemini/settings.json`
 - Junie: `plugins/junie/.junie/mcp/mcp.json`
 - GitHub Copilot: `plugins/copilot/.vscode/mcp.json`
+- Kilo Code: `plugins/kilo-code/kilo.jsonc`
 - Qodo: documented in `plugins/qodo/README.md` because official Qodo docs describe MCP setup through Agentic Tools or enterprise allow-lists, not automatic repo-local `.mcp.json` discovery
 - Zed: `plugins/zed/.zed/settings.json`
 - Windsurf/Cascade: `plugins/windsurf/mcp_config.json`
@@ -534,6 +553,25 @@ That folder currently contains:
 
 The generated Gemini MCP config launches both `studio mcp` and the bundled `wordpress-telemetry` MCP server. `GEMINI.md` is the project-level instruction file for Gemini CLI and Gemini Code Assist workflows.
 
+The Kilo Code output is generated to:
+
+```text
+plugins/kilo-code/
+```
+
+That folder currently contains:
+
+- `kilo.jsonc`
+- `AGENTS.md`
+- `.kilo/agents/wordpress-com.md`
+- `.kilo/rules/wordpress-com.md`
+- `.kilo/plugin/README.md`
+- `.kilo/skills/`
+- `scripts/wordpress-telemetry-mcp.mjs`
+- `README.md`
+
+The generated Kilo Code project config launches both `studio mcp` and the bundled `wordpress-telemetry` MCP server using Kilo's current `mcp` config shape. It uses Kilo-native rules, agents, skills, and AGENTS.md support documented at https://kilocode.ai/docs/.
+
 The Zed workspace output is generated to:
 
 ```text

plugins/kilo-code/.kilo/agents/wordpress-com.md

@@ -0,0 +1,10 @@
+---
+description: Builds, customizes, audits, and troubleshoots WordPress.com sites using Studio MCP and shared WordPress skills.
+mode: all
+---
+
+You are a WordPress.com specialist for Kilo Code.
+
+Use WordPress.com as the product name in user-facing text. For WordPress.com build, theme, block, plugin, site-creation, or audit requests, load the `wordpress-creator` skill first and follow its routing.
+
+Prefer the `wordpress-studio` MCP server for site operations, screenshots, block validation, `wp_cli`, and WordPress.com / Jetpack-connected workflows. Use the `wordpress-telemetry` MCP server for workflow telemetry when available.

plugins/kilo-code/.kilo/plugin/README.md

@@ -0,0 +1,5 @@
+# Kilo Code Plugins
+
+Kilo Code loads project-local JavaScript or TypeScript plugins from this directory.
+
+This WordPress.com output does not currently ship a Kilo-only plugin hook. The integration uses Kilo's native config, custom rules, agents, skills, AGENTS.md, and MCP support instead of inventing a plugin marketplace or a new backend service.

plugins/kilo-code/.kilo/rules/wordpress-com.md

@@ -0,0 +1,9 @@
+# WordPress.com for Kilo Code
+
+- Use the product name WordPress.com in user-facing text.
+- Prefer the configured `wordpress-studio` MCP server for site discovery, site changes, screenshots, block validation, and WordPress operations.
+- Use the bundled `wordpress-telemetry` MCP server for workflow telemetry emitted by this package.
+- Route implementation requests through the shared skills in `.kilo/skills/`, starting with `wordpress-creator` unless the user clearly asks for a narrower path.
+- Preserve existing project conventions and make the smallest complete change.
+- For themes, blocks, plugins, and content changes, inspect the current WordPress project structure before editing.
+- Use WordPress APIs, Gutenberg block markup, and WP-CLI-compatible operations instead of custom one-off storage or service layers.

plugins/kilo-code/.kilo/skills/auditing/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: auditing
+description: Audit a Studio-backed WordPress site for performance, accessibility, and visible frontend quality issues, then recommend or validate improvements.
+---
+
+# Auditing
+
+Use this skill when the user wants to review, optimize, or verify an existing WordPress site rather than primarily build new functionality.
+
+## Ownership
+
+This skill owns:
+
+- performance audits using Studio MCP tools
+- accessibility-focused review of color, contrast, motion, and readability
+- visible frontend quality review when the user asks for QA or polish
+- before-and-after audit comparison after fixes
+
+Use `studio` for site resolution, screenshots, and MCP tool usage details.
+
+## Principle
+
+Start with the smallest audit that answers the user's request.
+
+- If the user asks about speed, Core Web Vitals, or performance, prioritize the performance workflow.
+- If the user asks about accessibility, contrast, readability, or color usage, prioritize the accessibility workflow.
+- If the user asks for a general review, combine the relevant sections and keep the report practical.
+
+Do not invent automated checks that the available tools do not provide. When a conclusion comes from visual inspection or code reading rather than a dedicated tool, say so.
+
+## Workflow
+
+### 1. Resolve the target site
+
+Use `studio` to:
+
+- identify the site
+- ensure it is running
+- confirm the page or URL path to review
+
+If the user did not specify a page, default to `/`.
+
+### 2. Pick the audit scope
+
+Choose one or more of:
+
+- Performance Audit
+- Accessibility Review
+- Visual QA
+
+Tell the user which scope you are using when it is not obvious from the request.
+
+Once you begin the actual audit workflow, call `record_workflow_event` with `workflow: "auditing"` and `stage: "started"`.
+
+### 3. Performance Audit
+
+Use `need_for_speed` for the requested path.
+
+Interpret at least:
+
+- TTFB
+- FCP
+- LCP
+- CLS
+- total page weight
+- request count
+- DOM size
+- JS, CSS, image, and font breakdown
+
+Use these baseline thresholds:
+
+| Metric | Good | Needs Improvement | Poor |
+|-------|------|-------------------|------|
+| TTFB | < 800 ms | 800-1800 ms | > 1800 ms |
+| FCP | < 1800 ms | 1800-3000 ms | > 3000 ms |
+| LCP | < 2500 ms | 2500-4000 ms | > 4000 ms |
+| CLS | < 0.1 | 0.1-0.25 | > 0.25 |
+
+Use these page-composition warning signs:
+
+- DOM elements above 1500
+- total page weight above 3 MB
+- total requests above 80
+- scripts above 20 files or 500 KB total
+- stylesheets above 10 files or 200 KB total
+
+Translate findings into WordPress-specific actions where possible, such as:
+
+- reducing or replacing heavy plugins
+- deferring or removing non-critical JS
+- reducing oversized images
+- trimming unused theme CSS
+- checking duplicate font loads
+- simplifying wrapper-heavy block layouts
+
+### 4. Accessibility Review
+
+Use `take_screenshot` plus theme or plugin code inspection as needed.
+
+Focus on issues this repo can realistically help with:
+
+- low text/background contrast
+- weak CTA contrast or ambiguous button states
+- missing or unclear hover and focus states
+- motion that should respect `prefers-reduced-motion`
+- readability issues caused by font size, line height, or dense layouts
+- color choices that make important information hard to distinguish
+
+When the issue is visual, prefer `take_screenshot`-backed observations. Use `inspect_design` when the rendered DOM or computed styles would identify the root cause faster than code inspection.
+
+When the issue appears structural, inspect the relevant theme or plugin files before recommending a fix.
+
+### 5. Visual QA
+
+When the user wants a broader quality pass, use `take_screenshot` to check:
+
+- spacing and alignment
+- responsive layout issues
+- broken visual hierarchy
+- inconsistent component styling
+- awkward cropping or media balance
+
+Keep this section focused on visible problems that materially affect the site.
+
+### 6. Report clearly
+
+Summarize:
+
+- what you audited
+- the most important findings
+- the likely causes
+- the highest-value next fixes
+
+Prefer a short prioritized report over a long exhaustive list.
+
+### 7. Re-test after changes
+
+If fixes are made during the same task, re-run the relevant audit steps and compare before versus after.
+
+Call out what improved, what did not, and any remaining tradeoffs.
+
+When the audit workflow is complete, call `record_workflow_event` with `workflow: "auditing"` and `stage: "completed"`.
+
+## Important notes
+
+- `need_for_speed` results are synthetic measurements from a local Studio environment. Use them primarily for diagnosis and before-versus-after comparison, not as production truth.
+- Accessibility observations in this workflow are often based on visual review and code inspection rather than a dedicated automated accessibility scanner.
+- When performance, accessibility, and design issues conflict, explain the tradeoff instead of over-optimizing one dimension silently.