moicle 1.6.0 → 2.0.0

package/assets/skills/fix/incident/SKILL.md

@@ -0,0 +1,272 @@
+---
+name: fix-incident
+description: Incident response workflow for handling production issues. Use when there's an incident, outage, production down, or when user says "incident", "outage", "production down", "service down", "emergency".
+---
+
+# Incident Response Workflow
+
+Structured workflow for handling production incidents from triage to postmortem. **Speed > completeness** during P1/P2 — mitigation first, root cause after.
+
+## When to use this skill
+
+- ✅ Production is down or degraded right now
+- ✅ Users are impacted, on-call has been paged
+- ✅ Need to coordinate response, mitigation, comms, and postmortem
+- ❌ Bug is reported but no users impacted → use `/fix:hotfix`
+- ❌ Already mitigated, need to find root cause → use `/fix:root-cause`
+- ❌ Postmortem only, no active incident → jump to Phase 5
+
+---
+
+## Workflow
+
+```
+TRIAGE → INVESTIGATE → MITIGATE → RESOLVE → POSTMORTEM
+   ↓           ↓            ↓          ↓          ↑
+ comms      comms        comms      comms      learn
+```
+
+## Read Architecture First
+
+Before responding:
+1. `~/.claude/architecture/ddd-architecture.md`
+2. Stack-specific doc for the affected service
+3. Runbook for the affected component (`docs/runbooks/` or wiki)
+
+---
+
+## Severity Levels
+
+| Level | Description | Response Time | Examples |
+|-------|-------------|---------------|----------|
+| **P1** | Critical — complete outage / data loss / security breach | <15 min | Site down, DB corrupted, secret leak |
+| **P2** | High — major degradation, 50%+ users affected | <1 h | Login broken, payment failing |
+| **P3** | Medium — partial degradation, <50% users | <4 h | One feature broken |
+| **P4** | Low — minor issue, no significant impact | <24 h | UI glitch |
+
+---
+
+## Phase 1: TRIAGE (5–15 min)
+
+**Goal:** classify severity, assemble response, start comms.
+
+### Actions
+1. Capture: what, when, who's affected, error messages, recent deploys
+2. Assign severity (P1–P4)
+3. Open incident channel (`#incident-{date}-{short-name}`)
+4. Assign roles:
+   - **Incident Commander (IC)** — coordinates, makes decisions
+   - **Tech Lead** — investigates / fixes
+   - **Comms Lead** — updates stakeholders
+5. Page on-call for affected service
+6. Send first status update (template below)
+
+### First update template
+```
+[INCIDENT] {severity} {service} — {one-line impact}
+Detected: {timestamp}
+Status: investigating
+Channel: #incident-{slug}
+Next update: {time}
+```
+
+### Gate
+- [ ] Severity assigned
+- [ ] IC + Tech Lead identified
+- [ ] Incident channel open
+- [ ] First status sent
+
+---
+
+## Phase 2: INVESTIGATE (parallel with comms)
+
+**Goal:** find what's broken — don't fix yet, identify it.
+
+### Check in this order
+1. **Recent deploys** — last 24h. Roll back candidate?
+2. **Monitoring dashboards** — error rate, latency, saturation, traffic (the 4 golden signals)
+3. **Logs** — error spikes, new error types
+4. **Dependencies** — upstream services, DB, cache, queue, external APIs
+5. **Infrastructure** — CPU, memory, disk, network, certificate expiry, DNS
+
+### Common patterns
+| Symptom | Likely cause |
+|---------|-------------|
+| Errors only on new code path | Bad deploy → rollback |
+| Errors across all paths | Infra (DB, cache, network) |
+| Slow but not erroring | Resource saturation / external API slowdown |
+| Intermittent | Cache, race condition, flapping dependency |
+| Started exactly on a cron tick | Scheduled job |
+
+### Gate
+- [ ] Suspected cause identified (even if not yet confirmed)
+- [ ] Mitigation candidates listed
+- [ ] Update sent to incident channel
+
+---
+
+## Phase 3: MITIGATE (fast, reversible)
+
+**Goal:** stop the bleeding. Don't fix root cause yet.
+
+### Mitigation options (pick fastest reversible)
+| Option | When | Reversibility |
+|--------|------|---------------|
+| Rollback deploy | Recent deploy is suspect | Easy |
+| Feature flag off | Bad feature behind flag | Easy |
+| Scale up | Resource saturation | Easy |
+| Failover | Region / instance down | Medium |
+| Block traffic | Bot / DDoS | Medium |
+| DB restore | Data corruption | Hard — last resort |
+
+### Rules
+- **One change at a time.** If you change 3 things and it gets better, you don't know which fixed it.
+- **Announce before doing.** "Rolling back to {sha} in 60s." Then do it.
+- **Time-box.** If a mitigation doesn't work in 10 min, try the next one.
+
+### Verify mitigation
+- [ ] Error rate dropping in monitoring
+- [ ] Users confirming (sample check)
+- [ ] No new alerts firing
+
+### Gate
+- [ ] Impact reduced (errors down, users unblocked)
+- [ ] Mitigation status sent to channel
+- [ ] Severity downgraded if appropriate
+
+---
+
+## Phase 4: RESOLVE
+
+**Goal:** apply the permanent fix and verify.
+
+### Actions
+1. Confirm root cause (use `/fix:root-cause` workflow if not obvious)
+2. Implement permanent fix following stack architecture
+3. Add test that would have caught this
+4. Deploy fix through normal pipeline (don't skip CI even under pressure — unless explicitly authorized)
+5. Monitor for {N} hours post-deploy
+6. Remove temporary mitigation (e.g., re-enable feature flag) only after fix proven stable
+
+### Gate
+- [ ] Root cause confirmed
+- [ ] Fix deployed
+- [ ] Regression test added and passing
+- [ ] Monitoring shows healthy metrics for ≥1 hour
+- [ ] Incident marked resolved in channel
+
+---
+
+## Phase 5: POSTMORTEM
+
+**Goal:** learn from this so it doesn't happen again. **Blameless.**
+
+### Schedule
+- Within 48h of resolution for P1/P2
+- Within 1 week for P3
+- Optional for P4 (only if recurring pattern)
+
+### Postmortem template
+
+```markdown
+# Postmortem: {service} {date}
+
+## Summary
+{1-paragraph: what happened, impact, duration}
+
+## Impact
+- Users affected: {N or %}
+- Duration: {detected → mitigated → resolved}
+- Revenue / SLA impact: {if applicable}
+
+## Timeline (UTC)
+| Time | Event |
+|------|-------|
+| HH:MM | Deploy of {sha} |
+| HH:MM | First alert fired |
+| HH:MM | IC paged |
+| HH:MM | Mitigation: rollback to {sha} |
+| HH:MM | Error rate normal |
+| HH:MM | Permanent fix deployed |
+
+## Root Cause
+{Technical cause — what code / config / data caused this}
+
+## Contributing Factors
+- {Factor 1, e.g., test gap}
+- {Factor 2, e.g., missing alert}
+
+## What Went Well
+- {e.g., fast detection, clear rollback path}
+
+## What Didn't Go Well
+- {e.g., took 20 min to identify suspect deploy}
+
+## Action Items
+| # | Action | Owner | Due | Severity |
+|---|--------|-------|-----|----------|
+| 1 | {add alert for X} | @alice | {date} | high |
+| 2 | {add regression test} | @bob | {date} | medium |
+```
+
+### Action item rules
+- Each action item has owner + due date
+- Track to completion (open a ticket, link from postmortem)
+- "Better testing" is NOT an action item — be specific ("add test for X case")
+
+---
+
+## Communication Templates
+
+**Status update (every {N} min during incident)**
+```
+[UPDATE {time}] {service} — {status}
+Impact: {what users see}
+Action: {what we're doing}
+Next update: {time}
+```
+
+**Resolved**
+```
+[RESOLVED {time}] {service}
+Root cause: {one line}
+Mitigation: {what we did}
+Permanent fix: {ETA or done}
+Postmortem: {date}
+```
+
+---
+
+## Hard Rules
+
+- **Speed > completeness during P1/P2** — mitigate first, perfect later
+- **One change at a time** during mitigation
+- **Blameless postmortems** — focus on system, not person
+- **Don't skip CI** for the fix unless explicitly authorized by IC
+- **Don't close the incident** until monitoring is healthy for ≥1 hour
+- **Action items must have owner + date** — otherwise they don't happen
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Bug reported but no active incident | `/fix:hotfix` |
+| Root cause unclear, need deep investigation | `/fix:root-cause` |
+| Need to roll back deployment | (use ops runbook, not a skill) |
+| Documenting postmortem as a doc | `/docs:write` |
+
+---
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| TRIAGE | `@devops` | Infra + monitoring context |
+| INVESTIGATE | Stack-specific dev agent | Code-level debugging |
+| INVESTIGATE | `@security-audit` | If suspected breach / leak |
+| INVESTIGATE | `@db-designer` | If DB / data issue |
+| MITIGATE | `@devops` | Rollback / scale / failover |
+| RESOLVE | Stack-specific dev agent | Permanent fix |
+| POSTMORTEM | `@docs-writer` | Write postmortem doc |

package/assets/skills/{fix-pr-comment → fix/pr-comment}/SKILL.md

@@ -8,10 +8,19 @@ args: PR_NUMBER
 
 Workflow for fetching and fixing review comments from a pull request.
 
+## When to use this skill
+
+- ✅ Reviewer left comments on an open PR and you need to address each one
+- ✅ You want to track which comments are resolved vs still open
+- ✅ Need to post structured responses back to GitHub
+- ❌ Reviewing PR yourself (you're the reviewer) → use `/review:pr`
+- ❌ No PR yet, just want to clean up branch → use `/review:branch`
+- ❌ Need to fix a brand-new bug found by reviewer → use `/fix:hotfix` first, then this skill
+
 ## Usage
 
 ```
-/fix-pr-comment {PR_NUMBER}
+/fix:pr-comment {PR_NUMBER}
 ```
 
 ## Workflow Overview
@@ -281,3 +290,23 @@ PR comments are properly addressed when:
 3. Changes pushed to the PR branch
 4. Reviewers notified for re-review
 5. No new issues introduced
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| You are the reviewer | `/review:pr` |
+| Self-review before pushing again | `/review:branch` |
+| Fixing a bug surfaced by review | `/fix:hotfix` |
+| Comment requests architecture refactor | `refactor` → then this skill |
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| ANALYZE | `@code-reviewer` | Triage comments by severity |
+| FIX | Stack-specific dev agent | Apply code changes |
+| FIX | `@security-audit` | If comment flagged security |
+| RESPOND | `@docs-writer` | Polish written responses |

package/assets/skills/fix/root-cause/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: fix-root-cause
+description: Deep bug investigation workflow for hard-to-trace errors. Systematic root cause analysis — no guessing, no blind fixes. Use when user says "deep debug", "deep-debug", "trace bug", "find root cause", "hard bug", "investigate bug".
+---
+
+# Deep Bug Investigation
+
+For hard bugs that have been "fixed" multiple times without success. **DO NOT guess** — trace step by step to the root cause.
+
+## When to use this skill
+
+- ✅ Same bug keeps coming back after multiple "fixes"
+- ✅ "Sometimes works, sometimes doesn't" — likely hidden state
+- ✅ Error is inside a vendor library / framework internals
+- ✅ Local and production behave differently
+- ❌ Bug is well understood and just needs a fix → use `/fix:hotfix`
+- ❌ Production is currently down with users impacted → use `/fix:incident` first, deep-debug after mitigation
+
+---
+
+## Workflow
+
+```
+COLLECT → VERIFY → TRACE → ROOT CAUSE → CHECK HIDDEN STATE → FIX → VERIFY
+```
+
+---
+
+## Step 1: Collect evidence
+
+Record exactly, **do NOT interpret**:
+
+- Exact error message
+- Stack trace: file, line number, call chain
+- Which environment is affected (production / staging / local)
+- Happens every time or only in certain cases
+
+### Gate
+- [ ] Error message captured verbatim
+- [ ] Stack trace captured (or "no stack trace" noted)
+- [ ] Reproduction frequency known
+
+---
+
+## Step 2: Verify the code that is actually running
+
+**DO NOT assume production code = local code.**
+
+- Identify the exact version / commit currently deployed
+- Compare it against the code you are reading locally
+- If they DIFFER → read the deployed version before analyzing further
+
+### Gate
+- [ ] Deployed commit identified
+- [ ] Local checkout matches deployed commit (or differences noted)
+
+---
+
+## Step 3: Trace the execution path
+
+The most important step. Go from entry point → failing line. Trace **EVERY** step, **DO NOT skip**.
+
+### 3a. Entry point → error line
+- Where does the request / event / job enter from?
+- Which function calls which? Follow the stack trace exactly
+- How is data passed through each layer?
+
+### 3b. Where does the faulty data come from?
+- Where is the faulty variable created / loaded from?
+- Loaded directly from source (DB, API) or from cache / session?
+- Does it go through serialize → unserialize?
+- Does it go through any transform / convert step?
+
+### 3c. Type & state at the moment of failure
+- What is the actual type of the variable? (string, object, null, enum...)
+- What type does the code expect?
+- Why does the actual type differ from the expected one?
+
+### 3d. Framework internals (when error is inside vendor / library)
+- Read the source code at the EXACT line number from the stack trace
+- Trace backwards: who calls that method, with what arguments?
+- What condition drives the code into the failing branch?
+
+### Gate
+- [ ] Full call chain from entry → failure documented
+- [ ] Source of faulty data identified
+- [ ] Actual vs expected type / state recorded
+
+---
+
+## Step 4: Find the root cause — answer 3 questions
+
+1. **Why does it fail?** — the specific technical cause
+2. **Why didn't it fail before?** — what changed
+3. **Reproduction conditions?** — when it fails, when it doesn't
+
+If you cannot answer all 3 → return to Step 3, trace further.
+
+### Gate
+- [ ] All 3 questions answered with evidence (not speculation)
+
+---
+
+## Step 5: Check hidden state sources
+
+"Sometimes works, sometimes doesn't" bugs are usually caused by hidden state. Check in this order:
+
+### Cache / Serialization
+- Does the cached object lose internal state? (transient fields, lazy-loaded properties)
+- Does stale cache contain the old data format while new code expects the new format?
+- Does serialize / unserialize change the type? (int↔float, null handling, enum↔string)
+
+### Database / Storage
+- Do collation / encoding affect comparisons?
+- Do default values in the DB match the code's expectations?
+- Has the schema been updated on production yet?
+
+### Runtime / Compiled cache
+- Any compiled / cached config, routes, or views not cleared?
+- Does the bytecode cache (OPcache, compiled assets) serve the old file?
+- Does CDN / proxy cache serve a stale asset?
+
+### Environment
+- Are env vars on production correct and complete?
+- Does the runtime version (PHP, Node, Go, Python...) differ from local?
+- Do dependency versions differ?
+
+### Gate
+- [ ] All 4 categories considered (even if N/A — write that down)
+
+---
+
+## Step 6: Fix
+
+Only fix once you have answered the 3 questions from Step 4. The fix MUST:
+
+- Address the root cause, not the symptom
+- Handle the edge case discovered (stale cache, type mismatch)
+- Be defensive at data boundaries (cache, DB, external API) — NOT in internal logic
+- NOT break the normal code path in order to patch an edge case
+
+### Gate
+- [ ] Fix targets root cause, not symptom
+- [ ] Normal code path not regressed
+
+---
+
+## Step 7: Verify
+
+- Reproduce the failure conditions from Step 4 → confirm the fix works
+- Check the normal code path still works
+- If cache-related → test BOTH fresh load and cached load
+- Verify against the actually deployed version (repeat Step 2)
+
+### Gate
+- [ ] Original failure no longer reproducible
+- [ ] Normal flow still works
+- [ ] Cached / serialized paths both tested (if applicable)
+
+---
+
+## Final Report
+
+```markdown
+## Bug: {short description}
+
+### Root Cause
+{Answer to "why does it fail" — the actual technical cause}
+
+### Why it didn't fail before
+{What changed: deploy, dependency, data shape, config}
+
+### Reproduction
+{Exact steps to reproduce}
+
+### Fix
+- File: `path/to/file:line`
+- Change: {what changed and why this addresses root cause, not symptom}
+
+### Hidden state source
+{Cache / Storage / Runtime / Env — or "none"}
+
+### Verification
+- [x] Original failure no longer reproducible
+- [x] Normal path works
+- [x] Cached path works (if applicable)
+```
+
+---
+
+## Hard Rules
+
+- **DO NOT GUESS** — trace evidence, do not infer from variable names or "maybe it's..."
+- **DO NOT FIX BEFORE UNDERSTANDING** — fixing without knowing the root cause = creating a new bug
+- **VERIFY DEPLOYED CODE** — always check the running version, never assume production = local
+- **CHECK CACHE FIRST** — most "sometimes works, sometimes doesn't" bugs come from stale cached state
+- **ONE ROOT CAUSE** — every bug has one root cause. If multiple possibilities remain → trace further
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Bug is understood, just needs a fix | `/fix:hotfix` |
+| Production is down, users impacted | `/fix:incident` |
+| Need to write a regression test after the fix | `/review:tdd` |
+| Need to research how others solved similar bugs | `/research:web` |
+
+---
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| Step 3 (trace) | `@code-reviewer` | Independent reading of call chain |
+| Step 5 (hidden state) | `@db-designer` | Schema / collation / index checks |
+| Step 6 (fix) | Stack-specific dev agent | Implement defensive fix at boundary |
+| Step 7 (verify) | `@test-writer` | Regression test for the failing condition |

package/assets/skills/{onboarding → research/onboarding}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: onboarding
+name: research-onboarding
 description: Codebase onboarding workflow for understanding new projects. Use when joining a project, exploring codebase, or when user says "explain codebase", "onboard me", "new to project", "understand project", "explore codebase", "project overview".
 ---
 
@@ -7,39 +7,18 @@ description: Codebase onboarding workflow for understanding new projects. Use wh
 
 Complete workflow for understanding and navigating new codebases effectively.
 
-## IMPORTANT: Read Architecture First
+## When to use this skill
 
-**Before analyzing the codebase, you MUST read the appropriate architecture reference:**
+- ✅ Just joined a project / repo and need to ramp up
+- ✅ Returning to a codebase you haven't touched in months
+- ✅ Need to give a teammate a structured walkthrough
+- ❌ Want to generate full docs site → use `/docs:sync`
+- ❌ Need to fix a specific bug → use `/fix:hotfix` / `/fix:root-cause`
+- ❌ Only want a quick file lookup → just use `grep` / `find`
 
-### Global Architecture Files
-```
-~/.claude/architecture/
-├── clean-architecture.md    # Core principles for all projects
-├── flutter-mobile.md        # Flutter + Riverpod
-├── react-frontend.md        # React + Vite + TypeScript
-├── go-backend.md            # Go + Gin
-├── laravel-backend.md       # Laravel + PHP
-├── remix-fullstack.md       # Remix fullstack
-└── monorepo.md              # Monorepo structure
-```
-
-### Project-specific (if exists)
-```
-.claude/architecture/        # Project overrides
-```
-
-**Understanding the architecture first helps you grasp the codebase structure faster.**
+## Read Architecture First
 
-## Recommended Agents
-
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| SCAN | `@clean-architect` | Identify architecture patterns |
-| ANALYZE | `@clean-architect` | Analyze layer structure and boundaries |
-| ANALYZE | `@code-reviewer` | Code quality and conventions analysis |
-| ANALYZE | `@security-audit` | Security patterns review |
-| EXPLAIN | `@docs-writer` | Generate documentation/explanation |
-| GUIDE | `@docs-writer` | Create navigation guide |
+Read `ddd-architecture.md` + stack-specific doc first. Architecture context speeds up codebase comprehension dramatically.
 
 ## Workflow Overview
 
@@ -605,3 +584,25 @@ Onboarding is complete when you can:
 3. **Pair with Code** - Review existing features to learn patterns
 4. **Ask Questions** - Clarify anything unclear
 5. **Start Contributing** - Begin with small features following the architecture
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Generate full docs site after onboarding | `/docs:sync` |
+| Build first feature after onboarding | `/feature:new` |
+| First bug fix to learn the codebase | `/fix:hotfix` |
+| Author / update the onboarding doc itself | `/docs:write` |
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| SCAN | `@clean-architect` | Identify architecture patterns |
+| ANALYZE | `@clean-architect` | Layer structure + boundaries |
+| ANALYZE | `@code-reviewer` | Code conventions |
+| ANALYZE | `@security-audit` | Security patterns |
+| EXPLAIN | `@docs-writer` | Generate explanations |
+| GUIDE | `@docs-writer` | Navigation guide |

package/assets/skills/{spike → research/spike}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: spike
+name: research-spike
 description: Spike/Research workflow for exploring unknowns before committing to implementation. Use when researching, prototyping, doing proof of concept, or when user says "spike", "research", "prototype", "poc", "explore", "investigate".
 ---
 
@@ -7,40 +7,18 @@ description: Spike/Research workflow for exploring unknowns before committing to
 
 Time-boxed exploration workflow for investigating unknowns, validating assumptions, and de-risking decisions before committing to full implementation.
 
-## IMPORTANT: Read Architecture First
+## When to use this skill
 
-**Before starting any spike, you MUST read the appropriate architecture reference:**
+- ✅ Need to validate a technical assumption by building (not just reading)
+- ✅ Picking between 2+ technical options and need real comparison
+- ✅ De-risking a critical path before committing to it
+- ❌ Want to compare options via docs / SO / blogs only → use `/research:web`
+- ❌ Already decided on the approach → use `/feature:new`
+- ❌ Stuck on a known bug → use `/fix:root-cause`
 
-### Global Architecture Files
-```
-~/.claude/architecture/
-├── clean-architecture.md    # Core principles for all projects
-├── flutter-mobile.md        # Flutter + Riverpod
-├── react-frontend.md        # React + Vite + TypeScript
-├── go-backend.md            # Go + Gin
-├── laravel-backend.md       # Laravel + PHP
-├── remix-fullstack.md       # Remix fullstack
-└── monorepo.md              # Monorepo structure
-```
-
-### Project-specific (if exists)
-```
-.claude/architecture/        # Project overrides
-```
-
-**Understand the project structure and patterns before exploring alternatives.**
+## Read Architecture First
 
-## Recommended Agents
-
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| DEFINE | `@clean-architect` | Define research questions based on architecture |
-| RESEARCH | `@api-designer` | API/integration research |
-| RESEARCH | `@db-designer` | Data model research |
-| RESEARCH | `@security-audit` | Security implications |
-| PROTOTYPE | `@react-frontend-dev`, `@go-backend-dev`, `@laravel-backend-dev`, `@flutter-mobile-dev`, `@remix-fullstack-dev` | Stack-specific POC |
-| EVALUATE | `@clean-architect` | Architecture impact assessment |
-| EVALUATE | `@docs-writer` | Document findings |
+Read `ddd-architecture.md` + stack-specific doc to understand current patterns before exploring alternatives.
 
 ## Workflow Overview
 
@@ -533,3 +511,26 @@ echo "Date: [date]" >> experiments/README.md
 - ADR: [link]
 - Next steps: [list]
 ```
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Just need to compare options via docs (no code) | `/research:web` |
+| Spike done, ready to implement | `/feature:new` |
+| Spike revealed a bug to investigate | `/fix:root-cause` |
+| Document the ADR as a doc page | `/docs:write` |
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| DEFINE | `@clean-architect` | Frame research questions |
+| RESEARCH | `@api-designer` | API / integration research |
+| RESEARCH | `@db-designer` | Data model research |
+| RESEARCH | `@security-audit` | Security implications |
+| PROTOTYPE | Stack-specific dev agent | Build the POC |
+| EVALUATE | `@clean-architect` | Architecture impact |
+| EVALUATE | `@docs-writer` | Write the ADR |