feat: initial open marketplace with llm-security, config-audit, ultraplan-local

plugins/config-audit/.claude/rules/agent-development.md

@@ -0,0 +1,27 @@
+---
+paths: agents/**/*.md
+---
+
+# Agent Development Rules
+
+## Required Frontmatter
+
+All agent files MUST include this frontmatter:
+
+```yaml
+---
+name: descriptive-name
+description: |
+  Multi-line description of when to use this agent.
+model: opus|sonnet|haiku
+color: blue|green|yellow|purple|cyan|magenta
+tools: ["Read", "Glob", "Write"]
+---
+```
+
+## Conventions
+
+- Agent names use kebab-case with `-agent` suffix
+- Description must explain WHEN the agent should be used
+- Model choice: opus for analysis, sonnet for implementation, haiku for scanning
+- Color must be unique within the plugin

plugins/config-audit/.claude/rules/command-development.md

@@ -0,0 +1,24 @@
+---
+paths: commands/**/*.md
+---
+
+# Command Development Rules
+
+## Required Frontmatter
+
+All command files MUST include:
+
+```yaml
+---
+name: plugin:command
+description: Short description of what this command does
+allowed-tools: Read, Write, Bash, Task
+model: sonnet
+---
+```
+
+## Naming Convention
+
+- Commands use `plugin-name:action` format (e.g., `config-audit:analyze`)
+- Main router command uses just the plugin name (e.g., `config-audit`)
+- Description should be one line, actionable

plugins/config-audit/.claude/rules/state-management.md

@@ -0,0 +1,15 @@
+# State Update Rule
+
+After EVERY phase completes, you MUST update state.yaml using the Write tool (full file overwrite):
+
+1. Read: `~/.claude/config-audit/sessions/{session-id}/state.yaml`
+2. Update these fields:
+   - `current_phase`: the phase that just completed
+   - `completed_phases`: add the phase to array
+   - `next_phase`: the next phase in workflow
+   - `updated_at`: current timestamp
+3. Write the full file back
+
+**DO NOT output the phase summary until state.yaml is updated.**
+
+This ensures the workflow can resume correctly if interrupted.

plugins/config-audit/.claude/rules/ux-rules.md

@@ -0,0 +1,32 @@
+# Config-Audit UX Rules
+
+These rules apply to ALL config-audit commands. The goal is a professional, human-friendly experience.
+
+## Output Rules
+
+1. NEVER show raw JSON, stderr output, or scanner progress lines to the user
+2. ALL scanner Bash commands MUST use `--output-file <path> 2>/dev/null`
+3. Check exit code via `; echo $?` — codes 0, 1, 2 are normal (PASS/WARNING/FAIL). Only 3 is a real error
+4. Read output files with the Read tool, extract key metrics, and present formatted results
+5. NEVER let the user see tool call output that looks like diagnostic logs or stack traces
+
+## Narration Rules
+
+1. Before each major step, tell the user what's happening in plain language
+2. After scanners complete, briefly say what was found before showing details
+3. When spawning agents, tell the user what the agent does and approximate wait time
+4. If something takes more than a few seconds, set expectations: "This takes about 30 seconds..."
+
+## Formatting Rules
+
+1. Use markdown tables for structured data (area breakdowns, finding lists)
+2. Add one-sentence plain-language context for grades and scores — don't assume the user knows what "Level 4 Governed" means
+3. Separate test-fixture/example findings from real findings when showing counts
+4. End every command with context-sensitive next steps — explain what each command does, not just its name
+5. Adapt tone to results: A/B grades get encouraging context, D/F grades get empathetic, actionable guidance
+
+## Command Format
+
+1. Always use space-separated format in suggestions: `/config-audit plan` (NOT `/config-audit:plan`)
+2. Never reference commands that don't exist
+3. When suggesting next steps, explain WHY the user might want each option