ima-claude 2.20.0 → 2.26.0

package/plugins/ima-claude/skills/compound-bridge/SKILL.md

@@ -5,34 +5,26 @@ description: "Compound Engineering integration — memory bridge (Compound → V
 
 # Compound Bridge — Compound Engineering + ima-claude Integration
 
-Minimal connective tissue between Compound Engineering (structured workflows) and ima-claude (coding standards + memory). Removing this skill returns both systems to standalone behavior.
+Minimal connective tissue between Compound Engineering (structured workflows) and ima-claude (coding standards + memory).
 
 ## Memory Bridge: Compound → Vestige/Qdrant
 
-After Compound workflow events, **automatically store insights** without being asked:
+After Compound workflow events, store insights automatically:
 
 | After This Event | Store This | Where |
 |---|---|---|
-| `/workflows:compound` writes a solution | Root cause + key insight (1-2 sentences) | Vestige `smart_ingest`, node_type: `pattern` |
-| `/workflows:compound` writes a solution (>500 words) | Full solution content | Qdrant `qdrant-store`, collection: `compound-solutions` |
+| `/workflows:compound` writes solution | Root cause + key insight (1-2 sentences) | Vestige `smart_ingest`, node_type: `pattern` |
+| `/workflows:compound` writes solution (>500 words) | Full solution content | Qdrant `qdrant-store`, collection: `compound-solutions` |
 | `/workflows:plan` completes with research | Key decisions + approach chosen | Vestige `smart_ingest`, node_type: `decision` |
 | `/workflows:review` finds P1/P2 issues | Pattern summary of findings | Vestige `smart_ingest`, node_type: `pattern` |
 
-### Compound → Vestige Example
-
-After `/workflows:compound` finishes writing to `docs/solutions/`:
-
 ```
+# Vestige (all solutions)
 mcp__vestige__smart_ingest
-  content: "Root cause: {concise root cause}. Fix: {approach taken}. Key insight: {what we learned}"
+  content: "Root cause: {cause}. Fix: {approach}. Key insight: {learning}"
   node_type: "pattern"
-```
-
-### Compound → Qdrant Example (Large Solutions)
 
-For solutions over ~500 words, also store the full document in Qdrant for RAG retrieval:
-
-```
+# Qdrant (large solutions only)
 mcp__qdrant-memory__qdrant-store
   information: "{full solution content}"
   metadata: {"type": "compound-solution", "source": "docs/solutions/{filename}"}
@@ -40,49 +32,39 @@ mcp__qdrant-memory__qdrant-store
 
 ## Memory Bridge: Vestige → Compound Research
 
-When orchestrating `/workflows:plan`, **search Vestige before/alongside** the learnings-researcher agent:
+Before/alongside `/workflows:plan`, search Vestige:
 
 ```
 mcp__vestige__search query: "{feature keywords}" limit: 5
 ```
 
-Include Vestige results alongside file-based learnings, marked as cross-project provenance:
+Include results marked as cross-project provenance:
 
 ```markdown
 ### Prior Knowledge (Cross-Project — Vestige)
 - {vestige result 1}
-- {vestige result 2}
 
 ### Prior Solutions (Project — docs/solutions/)
 - {learnings-researcher results}
 ```
 
-This supplements but does not replace the learnings-researcher's `docs/solutions/` grep.
-
 ## Role Separation: Planning
 
-Both `task-master` and `/workflows:plan` handle planning. They have different lanes:
-
-| Need | Use | Why |
-|---|---|---|
-| Formal feature planning with research | `/workflows:plan` | Research agents, structured documentation, living plan file |
-| Ad-hoc work breakdown during implementation | `task-master` | Decomposition patterns, storage strategy, agent delegation |
-| Breaking a plan into executable tasks | Both | Plan creates the doc; task-master principles guide breakdown |
-
-### task-master Principles That Enhance Compound Workflows
-
-These apply when `/workflows:work` creates its task list:
+| Need | Use |
+|---|---|
+| Formal feature planning with research | `/workflows:plan` |
+| Ad-hoc work breakdown during implementation | `task-master` |
+| Breaking a plan into executable tasks | Both |
 
-- **Two-level max** agent delegation (Compound's swarm already respects this)
-- **Model selection**: Sonnet for execution, Opus for orchestration
-- **Minimal context principle** for subagents — only include what they need
-- **Vertical decomposition** for sequential work, **horizontal** for parallel
+task-master principles that apply inside `/workflows:work`:
+- Two-level max agent delegation
+- Sonnet for execution, Opus for orchestration
+- Minimal context for subagents
+- Vertical decomposition for sequential, horizontal for parallel
 
 ## Per-Project Config: `compound-engineering.local.md`
 
-Create this file in project roots where both systems are used. It tells Compound's review agents about our coding standards.
-
-### Template
+Create in project roots where both systems are used. Commit it early — it's persistent config, not a transient artifact.
 
 ```markdown
 ---
@@ -114,87 +96,52 @@ Language skills auto-activate by context:
 - Minimal context principle for subagents
 ```
 
-### When to Create
+Create when: project uses both ima-claude AND Compound workflows, or before first `/workflows:review`. Don't create for single-system projects.
 
-Create `compound-engineering.local.md` when:
-- A project uses both ima-claude skills AND Compound Engineering workflows
-- You're about to run `/workflows:review` for the first time in a project
+## Artifact Resilience
 
-Don't create it for projects that only use one system.
-
-## What Works Without This Skill
-
-These integrate naturally — no bridge needed:
-
-- ima-claude language/FP skills auto-activate during `/workflows:work` by file type
-- Compound's research agents (learnings-researcher, best-practices-researcher) fill gaps ima-claude doesn't cover
-- Compound's 15 specialized review agents complement our FP-focused standards
-- Compound's brainstorm workflow is genuinely new capability
-
-## Artifact Resilience: Surviving Branch Switches & Context Compaction
-
-Compound workflows write artifacts to the working tree (`docs/brainstorms/`, `docs/plans/`, `docs/solutions/`, `todos/`). These files are **not committed** during workflows. Git branch switching during `/workflows:work` **destroys them**. Context compaction loses agent results that reference them. This section prevents that.
+Compound writes artifacts to working tree (`docs/brainstorms/`, `docs/plans/`, `docs/solutions/`, `todos/`) but doesn't commit them. Branch switches destroy them. Context compaction loses references.
 
 ### Rule 1: Shadow Copy to `.claude/compound/`
 
-**After EVERY workflow artifact write**, immediately copy the file to `.claude/compound/`:
+After every workflow artifact write, copy to `.claude/compound/`:
 
-```
-# After /workflows:brainstorm writes to docs/brainstorms/
+```bash
 cp docs/brainstorms/{file}.md .claude/compound/brainstorms/{file}.md
-
-# After /workflows:plan writes to docs/plans/
 cp docs/plans/{file}.md .claude/compound/plans/{file}.md
-
-# After /workflows:compound writes to docs/solutions/
 cp docs/solutions/{category}/{file}.md .claude/compound/solutions/{category}/{file}.md
-
-# After /workflows:review writes to todos/
 cp todos/{file}.md .claude/compound/todos/{file}.md
 ```
 
-Create directories with `mkdir -p` as needed. The `.claude/` directory is gitignored and **survives branch switches** — just like Claude Code's own plan files.
+Also shadow-copy on checkbox updates (`- [ ]` → `- [x]`). `.claude/` is gitignored and survives branch switches.
 
-**Also shadow-copy on edits**: When `/workflows:work` updates plan checkboxes (`- [ ]` → `- [x]`), copy the updated plan to the shadow location too.
+### Rule 2: Eager Memory Bridge
 
-### Rule 2: Eager Memory Bridge (Store Immediately, Not Just at Completion)
-
-Don't wait until a workflow finishes to bridge to memory. Store **immediately after each artifact write**:
+Store immediately after each artifact write, not at workflow completion:
 
 | After Writing | Store Immediately |
 |---|---|
-| Brainstorm document | Vestige `smart_ingest`: key decisions + open questions, node_type: `decision` |
-| Plan document | Vestige `smart_ingest`: approach + task list summary, node_type: `decision` |
+| Brainstorm | Vestige `smart_ingest`: key decisions + open questions, node_type: `decision` |
+| Plan | Vestige `smart_ingest`: approach + task list summary, node_type: `decision` |
 | Plan checkbox update | Vestige `smart_ingest`: progress snapshot (X of Y tasks done), node_type: `observation` |
-| Review todo file | Vestige `smart_ingest`: finding summary + priority, node_type: `pattern` |
-| Solution document | Vestige + Qdrant (per existing rules above) |
-
-This ensures that even if context compacts or the session dies, the knowledge survives in memory.
+| Review todo | Vestige `smart_ingest`: finding summary + priority, node_type: `pattern` |
+| Solution | Vestige + Qdrant (per rules above) |
 
 ### Rule 3: Pre-Branch-Switch Checkpoint
 
-**Before ANY `git checkout`, `git switch`, or worktree operation** during a Compound workflow:
-
-1. Verify all workflow artifacts have shadow copies in `.claude/compound/`
-2. If any are missing, create them immediately
-3. Store a Vestige snapshot: `smart_ingest` with content summarizing current workflow state (which phase, what's done, what's next), node_type: `observation`
-
-### Rule 4: Recovery from Shadow Copies
-
-If workflow artifacts are lost (branch switch, reset, or interrupted session):
+Before any `git checkout`, `git switch`, or worktree operation during a Compound workflow:
 
-1. Check `.claude/compound/` for shadow copies
-2. Restore them to their working-tree locations (`docs/plans/`, etc.)
-3. Check Vestige for the most recent workflow state snapshot
-4. Resume from where we left off
+1. Verify all artifacts have shadow copies in `.claude/compound/`
+2. Create any missing copies
+3. Vestige `smart_ingest`: current workflow state (phase, done, next), node_type: `observation`
 
-### Rule 5: Commit `compound-engineering.local.md` Early
+### Rule 4: Recovery
 
-This file is **persistent project config**, not a transient artifact. When creating or modifying `compound-engineering.local.md`, commit it to the current branch promptly so it survives branch switches via git rather than shadow copies.
+If artifacts are lost: check `.claude/compound/` → restore to working-tree locations → check Vestige for latest state snapshot → resume.
 
 ## What This Skill Does NOT Do
 
-- Modify the Compound Engineering plugin — it stays as-is from the marketplace
-- Create custom scripts or utilities — all integration is skill instructions
-- Add new MCP servers — uses existing Vestige, Qdrant, Serena
+- Modify the Compound Engineering plugin
+- Create custom scripts or utilities
+- Add new MCP servers
 - Force workflows — both systems remain independently functional

package/plugins/ima-claude/skills/design-to-code/SKILL.md

@@ -5,122 +5,87 @@ description: "Convert design screenshots into working WordPress code through a t
 
 # Design to Code
 
-Orchestrate the transformation of design screenshots into working WordPress code. Two phases, one skill — produce the implementation prompt (Phase A), then execute it (Phase B).
-
-You are the orchestrator. You analyze designs, compose prompts, delegate implementation, and verify results. You do NOT implement directly — you delegate to `ima-claude:wp-developer` agents.
-
----
+Two-phase workflow: screenshots → implementation prompt (Phase A) → working WordPress code (Phase B). You orchestrate; delegate implementation to `ima-claude:wp-developer`.
 
 ## Mode Selection
 
-Determine the mode from the user's input:
-
 ```
 What did the user provide?
 ├── Screenshots/mockups (no existing prompt)
-│   → Phase A: Design → Prompt
-│   → Read references/phase-a-design-to-prompt.md
-│
-├── An existing implementation prompt
-│   → Phase B: Prompt → Code
-│   → Read references/phase-b-prompt-to-code.md
-│
+│   → Phase A → references/phase-a-design-to-prompt.md
+├── Existing implementation prompt
+│   → Phase B → references/phase-b-prompt-to-code.md
 └── Screenshots + "implement this" / "full pipeline"
     → Phase A then Phase B in sequence
-    → Phase A produces prompt → user reviews → Phase B executes
 ```
 
----
-
 ## Required Skills
 
-Always load alongside this skill:
-- **`ima-brand`** — color palette, typography, mixins (needed for both phases)
-- **`ima-bootstrap`** — utility classes, grid system, components
-
-Phase B additionally needs:
-- **`php-fp-wordpress`** — WordPress development patterns, security, shortcodes
-
----
+- **`ima-brand`** — color palette, typography, mixins (both phases)
+- **`ima-bootstrap`** — utility classes, grid, components
+- **`php-fp-wordpress`** — WordPress patterns (Phase B only)
 
 ## Phase A: Design → Prompt
 
-Transform design screenshots into a detailed, section-by-section implementation prompt. Output: a ~200-300 line prompt file matching the team's established template structure.
-
-Before starting, search Qdrant for `design-to-prompt` to recall prior lessons.
-
-### Steps (read `references/phase-a-design-to-prompt.md` for detailed procedures)
-
-1. **GATHER** — Fetch Jira context + receive screenshots + explore codebase (parallel)
-2. **ANALYZE** — Load brand palette from `ima-brand` (**must complete before COMPOSE**)
-3. **CROP** — Full view → section detection → detail crops (iterative PIL cropping)
-4. **EXTRACT** — Per crop: exact text, icons, colors, layout, spacing
-5. **MAP** — Visual elements → brand variables, components → existing shortcodes
-6. **COMPOSE** — Write prompt using `references/prompt-template.md` structure
-7. **VALIDATE** — Re-check each section against its crop for accuracy
+Output: ~200-300 line prompt file matching team template. Search Qdrant for `design-to-prompt` before starting.
 
-**Output**: Save prompt to `docs/designs/{ticket}/PROMPT.md` and Serena memory as `{feature-name}-plan`.
+| Step | Action |
+|------|--------|
+| GATHER | Fetch Jira context + receive screenshots + explore codebase (parallel) |
+| ANALYZE | Load brand palette from `ima-brand` — must complete before COMPOSE |
+| CROP | Full view → section detection → detail crops (iterative PIL cropping) |
+| EXTRACT | Per crop: exact text, icons, colors, layout, spacing |
+| MAP | Visual elements → brand variables, components → existing shortcodes |
+| COMPOSE | Write prompt using `references/prompt-template.md` structure |
+| VALIDATE | Re-check each section against its crop for accuracy |
 
-After Phase A, present the prompt to the user. Stop here unless running full pipeline.
-
----
+Save prompt to `docs/designs/{ticket}/PROMPT.md` and Serena memory as `{feature-name}-plan`. Present to user; stop here unless running full pipeline.
 
 ## Phase B: Prompt → Code
 
-Execute an implementation prompt to produce working WordPress code. Input: a structured prompt (from Phase A or user-provided).
-
-Before starting, search Qdrant for `design-to-code` to recall prior lessons.
+Search Qdrant for `design-to-code` before starting.
 
-### Steps (read `references/phase-b-prompt-to-code.md` for detailed procedures)
-
-1. **RESEARCH** — Brand SCSS files + current code + component libraries (parallel explorers)
-2. **ARCHITECTURE** — New file vs modify, function reuse, component migration decision
-3. **DECOMPOSE** — Stories by page section; Story 1 = foundation, Stories 2-N = parallel fills, final = polish
-4. **IMPLEMENT** — Delegate to `ima-claude:wp-developer` per story with precise prompts
-5. **REVIEW** — Verify copy, colors, element order, asset paths (orchestrator review before visual test)
-6. **VISUAL-QA** — Compile SASS → screenshot desktop + mobile → compare to design → iterate
-
----
+| Step | Action |
+|------|--------|
+| RESEARCH | Brand SCSS files + current code + component libraries (parallel explorers) |
+| ARCHITECTURE | New file vs modify, function reuse, component migration decision |
+| DECOMPOSE | Stories by page section; Story 1 = foundation, Stories 2-N = parallel fills, final = polish |
+| IMPLEMENT | Delegate to `ima-claude:wp-developer` per story with precise prompts |
+| REVIEW | Verify copy, colors, element order, asset paths before visual test |
+| VISUAL-QA | Compile SASS → screenshot desktop + mobile → compare to design → iterate |
 
 ## Critical Guardrails
 
-Read `references/guardrails.md` for the complete set. The top 5 (each learned from a real failure):
+Full set in `references/guardrails.md`. Top 5:
 
-1. **Never hardcode colors** — always brand SCSS variables or Bootstrap utilities
-2. **Always verify asset paths exist** — Glob/grep before referencing; check existing usage patterns
-3. **Always provide exact copy text** — never let agents paraphrase; include verbatim text in quotes
-4. **Load brand palette BEFORE composition** — informs every color reference on first pass
-5. **Check site header/footer first** — don't build custom components that duplicate existing site elements
+1. Never hardcode colors — use brand SCSS variables or Bootstrap utilities
+2. Always verify asset paths exist — Glob/grep before referencing
+3. Always provide exact copy text — include verbatim text in quotes, never let agents paraphrase
+4. Load brand palette BEFORE composition — informs every color reference on first pass
+5. Check site header/footer first — don't build components that duplicate existing site elements
 
----
-
-## Agent Delegation Model
+## Agent Delegation
 
 | Role | Agent | When |
-|---|---|---|
+|------|-------|------|
 | Orchestrator | opus (you) | All phases — research, planning, decomposition, delegation, review, surgical fixes |
 | Codebase explorer | `ima-claude:explorer` (haiku) | GATHER/RESEARCH: find existing shortcodes, templates, SCSS files |
 | Implementer | `ima-claude:wp-developer` (sonnet) | IMPLEMENT: write PHP/SCSS with skills: ima-brand, ima-bootstrap, php-fp-wordpress |
-| Reviewer | `ima-claude:reviewer` (sonnet, read-only) | REVIEW: brand compliance + accessibility audit (for larger implementations) |
-
-Orchestrator does surgical fixes (<5 lines) directly via Edit tool. Anything larger → delegate to wp-developer.
+| Reviewer | `ima-claude:reviewer` (sonnet, read-only) | REVIEW: brand compliance + accessibility audit (larger implementations) |
 
----
+Orchestrator does surgical fixes (<5 lines) directly via Edit. Anything larger → delegate to wp-developer.
 
 ## Qdrant Integration
 
-Before each phase, search Qdrant for prior lessons:
-- Phase A: `qdrant_find("design-to-prompt workflow")` — retrieves methodology, cropping techniques, composition decisions
-- Phase B: `qdrant_find("design-to-code implementation")` — retrieves decomposition patterns, delegation templates, QA patterns
-
----
+- Phase A: `qdrant_find("design-to-prompt workflow")`
+- Phase B: `qdrant_find("design-to-code implementation")`
 
 ## Related Skills
 
 | Skill | Relationship |
-|---|---|
+|-------|------|
 | `ima-brand` | Required — color palette, typography, mixins |
 | `ima-bootstrap` | Required — utility classes, grid, components |
-| `php-fp-wordpress` | Required for Phase B — WordPress dev patterns |
-| `task-master` | Optional — for complex multi-page designs needing Epic > Story > Task decomposition |
-| `prompt-starter` | Pattern borrowed — Phase A follows its "builder not executor" philosophy |
+| `php-fp-wordpress` | Required for Phase B |
+| `task-master` | Optional — complex multi-page designs needing Epic > Story > Task |
+| `prompt-starter` | Phase A follows its "builder not executor" philosophy |