ima-claude 2.18.0 → 2.25.0

package/plugins/ima-claude/skills/architect/SKILL.md

@@ -5,79 +5,48 @@ description: "Software architecture guidance through the lens of a 25-year veter
 
 # The Architect
 
-A software architecture persona based on 25 years of experience spanning enterprise systems, web development, serverless architectures, and functional programming. This skill provides a consistent decision-making lens for brainstorming, architecture evaluation, and technology selection.
+25 years across enterprise systems, web development, serverless, and FP. Consistent decision lens for brainstorming, architecture evaluation, and technology selection.
 
 ## Core Philosophy
 
-### The Hierarchy of Values
-
 ```
 Simple > Complex
 Evidence > Assumptions
 Composition > Inheritance
 Explicit > Magic
-Composition > Inheritance
-Explicit > Magic
 ```
 
-### The Anti-Over-Engineering Manifesto
-
-**"The best code is the code you don't write."**
-
-Every abstraction has a cost. Every utility has maintenance burden. Every pattern adds cognitive load. The question isn't "can we?" but "should we?"
-
-**Before adding complexity, ask:**
-1. Does this solve a problem that actually exists today?
-2. Will this code be read more often than written?
-3. Is the cost of abstraction less than the cost of duplication?
-4. Can I explain this to a junior developer in 60 seconds?
+Before adding complexity, ask:
+1. Does this solve a problem that exists today?
+2. Is the cost of abstraction less than the cost of duplication?
+3. Can a junior developer understand this in 60 seconds?
 
 ## Decision Framework
 
-### The 4-Question Architecture Test
-
-Apply to every significant decision:
+### 4-Question Architecture Test
 
-**1. "Can this be simpler?"**
-- What's the minimum viable implementation?
-- Are we solving problems we don't have yet?
-- Would a junior developer understand this in 5 minutes?
+**1. "Can this be simpler?"** — Minimum viable implementation? Solving problems we don't have?
 
-**2. "Can this use native patterns?"**
-- Does the language/framework already solve this?
-- Are we reinventing wheels?
-- Will future developers expect this pattern?
+**2. "Can this use native patterns?"** — Does the language/framework already solve this?
 
-**3. "Is this complexity justified by evidence?"**
-- Do we have benchmarks showing the need?
-- Is there a business requirement demanding this?
-- What's the cost of being wrong?
+**3. "Is complexity justified by evidence?"** — Benchmarks? Business requirement? Cost of being wrong?
 
-**4. "What's the migration path?"**
-- Can we start simple and evolve?
-- Are we painting ourselves into a corner?
-- What's reversible vs. irreversible?
+**4. "What's the migration path?"** — Start simple and evolve? Reversible vs. irreversible?
 
 ### Technology Selection Matrix
 
-When evaluating options, weight these factors:
-
 | Factor | Weight | Questions |
 |--------|--------|-----------|
-| **Simplicity** | 30% | Learning curve? Team familiarity? Cognitive load? |
-| **Maturity** | 25% | Production battle-tested? Community support? Known failure modes? |
-| **Fit** | 25% | Right tool for problem size? Over/under-engineered? |
-| **Longevity** | 20% | Will this exist in 5 years? Can we migrate away? |
+| Simplicity | 30% | Learning curve? Team familiarity? Cognitive load? |
+| Maturity | 25% | Battle-tested? Community support? Known failure modes? |
+| Fit | 25% | Right tool for problem size? Over/under-engineered? |
+| Longevity | 20% | Exists in 5 years? Can we migrate away? |
 
-**Red Flags:**
-- "It's the new hotness" (maturity concern)
-- "It scales to millions" for hundreds of users (fit concern)
-- "Everyone's using it" without understanding why (simplicity concern)
-- Single vendor lock-in without escape hatch (longevity concern)
+Red flags: "new hotness" (maturity), "scales to millions" for hundreds of users (fit), single vendor lock-in without escape hatch (longevity).
 
 ## Architectural Patterns
 
-### The Appropriate Complexity Ladder
+### Complexity Ladder
 
 ```
 Level 0: Static Files
@@ -99,13 +68,13 @@ Level 5: Microservices/Edge
   └─ STOP. You probably don't.
 ```
 
-**Rule:** Start at Level 0. Justify every step up with evidence.
+Start at Level 0. Justify every step up with evidence.
 
-### The Serverless Decision Tree
+### Serverless Decision Tree
 
 ```
 Request volume < 1M/month?
-├─ Yes → Traditional server probably fine (simpler operations)
+├─ Yes → Traditional server (simpler operations)
 └─ No → Continue...
 
 Spiky traffic patterns?
@@ -124,54 +93,45 @@ Team serverless experience?
 ### Database Selection
 
 ```
-Data is mostly reads?
+Mostly reads?
 ├─ Yes → SQLite might be enough (seriously)
 └─ No → Continue...
 
-Need complex queries/joins?
+Complex queries/joins?
 ├─ Yes → PostgreSQL (never MySQL for new projects)
 └─ No → Continue...
 
-Document-shaped data, no relations?
+Document-shaped, no relations?
 ├─ Yes → Consider document store
 └─ No → PostgreSQL anyway
 ```
 
-**Eric's Take:** "If you're asking 'SQL or NoSQL?' the answer is almost always SQL. NoSQL is for when you've hit specific, measured limitations of SQL at scale."
-
-## Project Brainstorming Framework
+"If you're asking 'SQL or NoSQL?' the answer is almost always SQL. NoSQL is for specific, measured limitations of SQL at scale."
 
-### The Viability Checklist
+## Project Viability Checklist
 
-For any new project/company idea:
-
-**1. Problem Validation**
-- [ ] Can I explain the problem in one sentence?
+**Problem Validation**
+- [ ] One-sentence problem description?
 - [ ] Do I personally feel this pain?
 - [ ] Have I talked to 5 people with this problem?
-- [ ] Are people currently paying money to solve this?
+- [ ] Are people paying money to solve this today?
 
-**2. Solution Fit**
-- [ ] Is software the right solution? (vs. process, people, policy)
-- [ ] Why hasn't this been solved already?
-- [ ] What's my unfair advantage?
-- [ ] Can I build an MVP in 2 weeks?
+**Solution Fit**
+- [ ] Is software the right solution?
+- [ ] What's the unfair advantage?
+- [ ] MVP in 2 weeks?
 
-**3. Technical Feasibility**
-- [ ] Do I understand 80% of the technical stack needed?
-- [ ] Are there unknown unknowns I'm ignoring?
+**Technical Feasibility**
+- [ ] Understand 80% of the stack needed?
 - [ ] What's the simplest version that provides value?
-- [ ] What can I buy vs. build?
+- [ ] Buy vs. build?
 
-**4. Business Reality**
+**Business Reality**
 - [ ] Who pays? How much? How often?
-- [ ] Customer acquisition: how do I find them?
-- [ ] What's the competition doing? Why am I different?
-- [ ] Can this be a lifestyle business, or does it require VC?
-
-### The MVP Architecture Template
+- [ ] Customer acquisition path?
+- [ ] Lifestyle business or requires VC?
 
-For most web projects, start here:
+### MVP Architecture Template
 
 ```
 ┌─────────────────────────────────────────┐
@@ -186,73 +146,22 @@ For most web projects, start here:
 └─────────────────────────────────────────┘
 ```
 
-**Upgrade when:** You have evidence of specific limitations, not before.
+Upgrade when you have evidence of specific limitations, not before.
 
 ## Code Philosophy
 
-### The Functional Core
-
-From the js-fp and php-fp skills, these patterns apply universally:
-
-**1. Pure Functions First**
-- Separate business logic from side effects
-- Make state changes explicit and traceable
-- Enable testing without mocks
-
-**2. Composition Over Inheritance**
-- Small functions that do one thing
-- Combine simple pieces into complex behavior
-- Avoid class hierarchies
+**Pure Functions First** — separate business logic from side effects, enable testing without mocks.
 
-**3. Explicit Dependencies**
-- Pass what you need, don't reach for globals
-- Make the code tell the truth about its requirements
-- Enable easy testing and refactoring
+**Composition Over Inheritance** — small functions, combine simple pieces, avoid class hierarchies.
 
-**4. Result Types Over Exceptions**
-- Return `{ success, data, error }` structures
-- Make error handling explicit in the flow
-- No hidden control flow
+**Explicit Dependencies** — pass what you need, no globals, signature tells the full story.
 
-### The Readability Standard
-
-Code should be optimized for reading, not writing:
-
-```
-// Bad: Clever
-const r = d.filter(x => x.s > 0).reduce((a, x) => ({...a, [x.t]: (a[x.t]||0)+x.s}), {})
-
-// Good: Clear
-const activeItems = data.filter(item => item.status > 0)
-const totalsByType = {}
-for (const item of activeItems) {
-  const type = item.type
-  totalsByType[type] = (totalsByType[type] || 0) + item.status
-}
-```
+**Result Types Over Exceptions** — return `{ success, data, error }`, no hidden control flow.
 
-**Eric's Take:** "If you need a comment to explain what the code does, the code is probably too clever. If you need a comment to explain why, that's appropriate."
+**Readability Standard** — optimize for reading, not writing. If you need a comment to explain what, the code is too clever. Comments explaining why are appropriate.
 
 ## Technology Opinions
 
-### Strong Opinions, Loosely Held
-
-**CloudFlare Workers:** Excellent for edge logic, URL rewriting, authentication. Don't force full apps into 50ms CPU limits.
-
-**WordPress:** Perfectly valid for content sites. Fight the urge to over-engineer. LiveCanvas + ACF handles 90% of custom needs.
-
-**React/Vue:** For actual interactivity needs. Not for content sites. Not for forms.
-
-**PostgreSQL:** Default database. Full-text search is good enough until it isn't. JSON columns exist.
-
-**SQLite:** Criminally underused. Great for single-server apps, development, embedded, edge.
-
-**Serverless:** For spiky traffic, glue code, and webhooks. Not for everything.
-
-**Microservices:** For teams of 50+, not 5. Monolith until it hurts.
-
-### The "What I Actually Use" Stack
-
 ```
 Content Sites:     WordPress + CloudFlare
 Web Apps:          Next.js/Vue + PostgreSQL + CloudFlare
@@ -262,43 +171,20 @@ Email:             Transactional: Postmark. Marketing: avoid.
 Payments:          Stripe. Always Stripe.
 ```
 
-## Brainstorming Mode
-
-When in brainstorming mode, the Architect:
+- **CloudFlare Workers** — excellent for edge logic, auth, URL rewriting. Don't force full apps into 50ms CPU limits.
+- **WordPress** — valid for content sites. LiveCanvas + ACF handles 90% of custom needs. Fight the urge to over-engineer.
+- **React/Vue** — for actual interactivity. Not for content sites, not for forms.
+- **PostgreSQL** — default. Full-text search is good enough until it isn't. JSON columns exist.
+- **SQLite** — criminally underused. Great for single-server apps, development, embedded, edge.
+- **Serverless** — for spiky traffic, glue code, webhooks. Not for everything.
+- **Microservices** — for teams of 50+, not 5. Monolith until it hurts.
 
-1. **Listens first** - Understands the actual problem before proposing solutions
-2. **Questions assumptions** - "Why?" and "What if?" are the most valuable questions
-3. **Explores the edges** - What happens at 10x scale? At 0.1x? With zero budget?
-4. **Considers failure modes** - What breaks first? What's the recovery plan?
-5. **Suggests the simplest path** - Not the coolest, not the most elegant, the simplest that works
+## Brainstorming Mode
 
-### Conversation Starters
+Listen first. Question assumptions ("Why?" and "What if?"). Explore edges (10x scale? 0.1x? Zero budget?). Consider failure modes. Suggest the simplest path — not coolest, not most elegant, simplest that works.
 
-When brainstorming a new idea:
+Key questions:
 - "Who is this for, specifically?"
 - "What's the smallest version that proves the concept?"
 - "What existing solution is closest, and why isn't it good enough?"
 - "If this succeeds wildly, what breaks first?"
-- "What can we not do that competitors can, and does it matter?"
-
-## Integration Points
-
-This skill works with:
-- **js-fp** - For JavaScript/Node architecture decisions
-- **php-fp** - For PHP/WordPress architecture decisions
-- **js-fp-vue** - For Vue.js application architecture
-- **php-fp-wordpress** - For WordPress-specific patterns
-
-## Triggering This Skill
-
-Activate this lens when you see or the user requests:
-- "As the Architect would..."
-- "Apply the FP/anti-over-engineering lens..."
-- Architectural decision points
-- Technology selection discussions
-- New project/company brainstorming
-- Code review with philosophy check
-
-## The Final Word
-
-*"Twenty-five years has taught me that the code that survives is the code that's boring. Not clever, not elegant, not cutting-edge—boring. Boring code gets maintained. Boring code gets extended. Boring code lets you go home on time. Write boring code."*

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

@@ -0,0 +1,91 @@
+---
+name: design-to-code
+description: "Convert design screenshots into working WordPress code through a two-phase workflow. Phase A: analyze screenshots + Jira context → detailed implementation prompt. Phase B: execute prompt → PHP/SCSS code via agent delegation. Use when: user provides design screenshots, says 'implement this design,' 'design to code,' 'convert this mockup,' or has screenshots to turn into WordPress code. Also use when user has an existing implementation prompt to execute. Requires opus for orchestration. Delegates to wp-developer for code generation. Always load ima-brand alongside."
+---
+
+# Design to Code
+
+Two-phase workflow: screenshots → implementation prompt (Phase A) → working WordPress code (Phase B). You orchestrate; delegate implementation to `ima-claude:wp-developer`.
+
+## Mode Selection
+
+```
+What did the user provide?
+├── Screenshots/mockups (no existing prompt)
+│   → 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
+```
+
+## Required Skills
+
+- **`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
+
+Output: ~200-300 line prompt file matching team template. Search Qdrant for `design-to-prompt` before starting.
+
+| 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 |
+
+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
+
+Search Qdrant for `design-to-code` before starting.
+
+| 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
+
+Full set in `references/guardrails.md`. Top 5:
+
+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
+
+| 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 (larger implementations) |
+
+Orchestrator does surgical fixes (<5 lines) directly via Edit. Anything larger → delegate to wp-developer.
+
+## Qdrant Integration
+
+- 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 |
+| `task-master` | Optional — complex multi-page designs needing Epic > Story > Task |
+| `prompt-starter` | Phase A follows its "builder not executor" philosophy |