moicle 1.7.0 → 2.1.0

package/assets/skills/marketing/video/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: marketing-video
+description: Plan and produce video content strategy including scripts, storyboards, and production specs. Use when user says "create video", "video content", "video script", "video strategy", "youtube content", "video plan".
+---
+
+# Video Content Skill
+
+Plan video content end-to-end: strategy, script, storyboard, production spec, publishing schedule.
+
+## When to use this skill
+
+- ✅ Planning a video series or campaign (multi-video)
+- ✅ Need a script + storyboard + production spec for a single video
+- ✅ Repurposing existing long-form into shorts / clips
+- ❌ Just need ideas, not a plan → use `brainstorm`
+- ❌ Want full marketing plan (logo + content + video) → use `/marketing`
+- ❌ Writing a blog post or thread → use `/marketing:content`
+
+---
+
+## Workflow
+
+```
+STRATEGY → SCRIPT → STORYBOARD → PRODUCTION → PUBLISH
+```
+
+---
+
+## Phase 1: STRATEGY
+
+**Goal:** lock the audience, goal, channels, and series plan.
+
+### Gather brief
+
+Ask the user (skip what's already known):
+
+| Field | Example |
+|-------|---------|
+| Primary goal (pick 1) | brand awareness / tutorial / lead gen / community / thought leadership |
+| Audience | "Senior backend engineers evaluating Postgres tooling" |
+| Channels (pick ≤3) | YouTube long / YouTube Shorts / TikTok / Reels / LinkedIn / X / Twitch |
+| Cadence | "1 long video / week + 3 shorts" |
+| Series concept | "From-zero series: build a SaaS in 10 episodes" |
+| Tone | "Casual, technical, no fluff" |
+| Existing assets | brand kit URL, prior videos, channel stats |
+
+### Output: 1-page strategy
+
+```markdown
+## Video Strategy: {brand}
+- Goal: {one line}
+- Audience: {one line}
+- Channels: {list, with primary marked}
+- Cadence: {long-form + shorts schedule}
+- Series: {2-4 series, each with theme + episode count target}
+- Brand: {voice, colors, logo lockup}
+```
+
+### Gate
+- [ ] Goal + audience confirmed by user
+- [ ] Channels matched to where audience watches
+- [ ] At least 1 series concept defined
+
+---
+
+## Phase 2: SCRIPT
+
+**Goal:** write a script that holds attention from frame 1.
+
+### Universal structure
+
+```
+HOOK (≤10 sec, ≤30 sec for long-form)
+  - one of: contrarian claim / surprising number / pain question / curiosity gap
+INTRO (≤15 sec)
+  - what they'll get + why this person/channel
+BODY
+  - one idea per segment, each ≤90 sec for long-form, ≤15 sec for shorts
+  - pattern interrupt every 30-45 sec (cut, b-roll, on-screen text)
+PAYOFF
+  - the answer / the demo / the result
+CTA (≤10 sec)
+  - one ask: subscribe, link, comment with X
+```
+
+### Hook examples (pick a type, write 3 variants)
+
+| Type | Example |
+|------|---------|
+| Contrarian | "Everyone tells you to write tests first. Here's why I stopped." |
+| Number | "I shipped 47 features last quarter with 1 engineer. Here's how." |
+| Pain question | "Your DB is slow at 100k rows? That's a config issue, not a Postgres limit." |
+| Curiosity gap | "There's a feature in Go that nobody uses but it solves your timeout bug." |
+
+### Script length budget
+
+| Format | Total | Hook | Body | CTA |
+|--------|-------|------|------|-----|
+| YouTube long | 8-15 min | 10-30 s | 7-13 min | 10-30 s |
+| YouTube Short / Reel / TikTok | 30-60 s | ≤3 s | 25-50 s | ≤5 s |
+| LinkedIn native | 1-3 min | ≤5 s | 50 s - 2 min 30 s | ≤10 s |
+
+### Gate
+- [ ] Hook tested by reading frame 1 aloud — would you keep watching?
+- [ ] One idea per segment (no parallel threads)
+- [ ] Pattern interrupt every ≤45 sec (long-form)
+- [ ] CTA is one ask, not three
+
+---
+
+## Phase 3: STORYBOARD
+
+**Goal:** visual plan that the editor / camera-op can execute without asking questions.
+
+### Scene table (one row per cut)
+
+| # | Time | Visual | Audio | Text overlay | Asset needed |
+|---|------|--------|-------|--------------|--------------|
+| 1 | 0:00-0:08 | Talking head, medium shot | Hook line | (none) | — |
+| 2 | 0:08-0:25 | Screen recording: IDE | VO | "Step 1: install" | terminal recording |
+| 3 | 0:25-0:40 | B-roll: server rack | VO | (none) | stock or own footage |
+
+### Visual rules (project-wide)
+
+- Aspect ratio: 16:9 (YouTube long) / 9:16 (shorts, Reels, TikTok) / 1:1 (LinkedIn native fallback)
+- Captions ALWAYS burned in for shorts (most viewers watch muted)
+- Brand bug in bottom-right (long-form only) for first 5 sec + last 10 sec
+- Max 2 fonts (display + body)
+- Stick to brand palette (link to logo guidelines if available)
+
+### Gate
+- [ ] One row per cut
+- [ ] All assets listed and sourced (or "to record")
+- [ ] Captions plan in place for muted viewing
+- [ ] Aspect ratio matches the channel
+
+---
+
+## Phase 4: PRODUCTION
+
+**Goal:** ship a production-ready file the publisher can upload without rework.
+
+### Tech spec per channel
+
+| Channel | Resolution | FPS | Codec | Max length | Notes |
+|---------|-----------|-----|-------|-----------|-------|
+| YouTube long | 1080p or 4K | 30 / 60 | H.264 | 12 h | Chapters required for >5 min |
+| YouTube Shorts | 1080×1920 | 30 / 60 | H.264 | 60 s | Vertical |
+| TikTok | 1080×1920 | 30 / 60 | H.264 | 10 min | Caption per scene |
+| Instagram Reels | 1080×1920 | 30 | H.264 | 90 s | First frame = thumbnail |
+| LinkedIn native | 1920×1080 / 1080×1080 | 30 | H.264 | 10 min | Captions burned in |
+| X (Twitter) | 1280×720+ | 30 / 60 | H.264 | 2 min 20 s | Add caption file |
+
+### Audio
+- Voice: -3 dBFS peak, -16 LUFS integrated
+- Music bed: -20 dBFS under voice, royalty-cleared (Epidemic, Artlist, or licensed)
+- Cuts: trim every breath / um / "so" — tight pacing matters
+
+### Pre-publish checklist
+- [ ] Color graded (consistent across cuts)
+- [ ] Audio levels normalized
+- [ ] Captions / subtitles burned in (where required) and SRT file for accessibility
+- [ ] Thumbnail designed (3 variants for A/B if YouTube)
+- [ ] Title written (≤60 chars, includes primary keyword)
+- [ ] Description with timestamps, CTAs, links
+
+### Gate
+- [ ] Tech spec matches target channel
+- [ ] Thumbnail tested at small size (mobile feed)
+- [ ] First 3 sec works without sound
+
+---
+
+## Phase 5: PUBLISH
+
+**Goal:** get the video in front of the audience and measure.
+
+### Per-channel adaptation
+
+- **YouTube long:** publish + immediately pin a comment with key timestamps + first-hour engagement push
+- **Shorts:** publish 3-5x/week for algorithm; don't link in description (kills reach)
+- **TikTok:** publish in batches at 7 PM local; respond to first 10 comments within 1 hour
+- **LinkedIn:** native upload (don't link YouTube); post in first hour of work day
+- **X:** native video; thread = video + 3-5 text takeaways
+
+### Cross-posting
+- Cut shorts from long-form (3-5 per long video)
+- Convert key insight into LinkedIn carousel + X thread
+- Embed in blog post (boosts both)
+
+### Tracking
+- UTM tags on all description links: `?utm_source=youtube&utm_medium=video&utm_campaign={series}`
+- Watch: average view duration, retention curve (cliff = where to cut next time), CTR on thumbnail
+- Iterate: kill formats with <30% retention after 3 attempts
+
+### Gate
+- [ ] Adapted per channel (no copy-paste)
+- [ ] UTMs applied
+- [ ] Tracking dashboard updated
+
+---
+
+## Final Report
+
+```markdown
+## Video Plan: {brand / series}
+
+### Strategy
+- Goal: {one line}
+- Audience: {one line}
+- Channels: {primary + secondary}
+
+### Videos Planned (next 4 weeks)
+| # | Title | Format | Channel | Status |
+|---|-------|--------|---------|--------|
+| 1 | ... | long | YouTube | scripted |
+| 2 | ... | short | Reels + TikTok + Shorts | storyboard |
+
+### Production Backlog
+- {script ready, awaiting recording}
+- {recording done, awaiting edit}
+
+### Metrics
+- Baseline → Target per video and per series
+```
+
+---
+
+## Hard Rules
+
+- **Hook decides everything** — if first 3 sec doesn't work, nothing after matters
+- **Captions for muted viewing** — most feed views are sound-off
+- **One ask in the CTA** — multiple CTAs = zero conversions
+- **Vertical for mobile-first channels** — never reupload 16:9 to TikTok / Shorts
+- **Kill what doesn't work after 3 attempts** — don't keep producing for an audience that isn't there
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Full marketing plan (logo + content + video) | `/marketing` |
+| Need brand visuals first | `/marketing:logo` |
+| Repurpose video → blog / threads | `/marketing:content` |
+| Brainstorm video topics | `brainstorm` |
+
+---
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| STRATEGY | `@docs-writer` | Document the strategy brief |
+| SCRIPT | `@docs-writer` | Draft and tighten scripts |
+| STORYBOARD | `@docs-writer` | Scene descriptions |
+| PRODUCTION | `@devops` | Tech specs + encoding |
+| PUBLISH | `@docs-writer` | Channel adaptations + tracking |

package/assets/skills/research/onboarding/SKILL.md

@@ -0,0 +1,225 @@
+---
+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".
+---
+
+# Codebase Onboarding Workflow
+
+Ramp up on a new codebase quickly: structure, conventions, where things live, how to make a first change.
+
+## When to use this skill
+
+- ✅ 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`
+
+## Read Architecture First
+
+Detect stack with `~/.claude/architecture/_shared/stack-detection.md`. Read `ddd-architecture.md` + the stack doc. Architecture context speeds up everything below by 10x.
+
+---
+
+## Workflow
+
+```
+SCAN → ANALYZE → EXPLAIN → GUIDE (first commit checklist)
+```
+
+---
+
+## Phase 1: SCAN (10-20 min)
+
+**Goal:** map the territory before reading any business code.
+
+```bash
+# Structure
+tree -L 2 -I 'node_modules|vendor|dist|build|.git'
+
+# Tech surface
+ls -la | grep -E "package.json|pubspec.yaml|go.mod|composer.json|Dockerfile|Makefile"
+
+# Existing docs
+find . -maxdepth 3 -name "README*" -o -name "CONTRIBUTING*" -o -name "ARCHITECTURE*"
+
+# Activity
+git log --oneline -20
+git shortlog -sn --since=3months | head -10
+```
+
+### Capture
+- Top-level layout (≤2 levels)
+- Tech stack + main dependencies (5-10 biggest)
+- Existing docs found (read in next phase)
+- Active contributors + recent commit themes
+
+### Gate
+- [ ] Stack detected (or asked user if ambiguous)
+- [ ] Top-level structure understood
+- [ ] Existing docs inventoried
+
+---
+
+## Phase 2: ANALYZE (30-60 min)
+
+**Goal:** understand layer boundaries, conventions, and the "shape" of code.
+
+### Read in this order
+1. `README.md` — purpose + setup
+2. `ARCHITECTURE.md` / `CONTRIBUTING.md` if present
+3. **One existing module end-to-end** — pick the smallest with a full layer stack (e.g., `domain/user/`). Trace: entity → port → usecase → handler → test.
+4. Cross-domain wiring (event bus / DI / router registration)
+5. CI config (`.github/workflows/`, `Makefile`) — what's enforced?
+
+### Capture
+- Architecture pattern (DDD / MVC / clean / hexagonal — match against `ddd-architecture.md`)
+- Naming conventions (file, function, test)
+- Where business logic lives (usecase vs service vs handler)
+- How errors are returned (typed, panics, error wrapping)
+- Test framework + folder convention
+- How code reaches prod (CI checks, release process)
+
+### Gate
+- [ ] One module read end-to-end
+- [ ] Layer boundaries understood
+- [ ] Test + CI conventions known
+
+---
+
+## Phase 3: EXPLAIN
+
+**Goal:** produce a 1-page mental model that someone else can read.
+
+```markdown
+## Project: {name}
+
+### Purpose
+{1-2 sentences: what business problem this solves}
+
+### Stack
+- Language: {go 1.22 / node 20 / dart 3.x / ...}
+- Framework: {gin / nestjs / remix / flutter ...}
+- DB: {postgres + sqlc / prisma / eloquent ...}
+- Infra: {docker, k8s on GKE, redis, kafka ...}
+
+### Architecture
+{1 sentence: e.g., "DDD with hexagonal — domain-pure, infra implements ports"}
+
+```
+{ascii or mermaid: top-level layer diagram}
+```
+
+### Domains
+| Domain | Responsibility |
+|--------|----------------|
+| {name} | {one line} |
+
+### Where to find things
+| If you need to... | Look in |
+|-------------------|---------|
+| Add a route | `application/ports/http/<domain>_handler` |
+| Add business logic | `domain/<domain>/usecases` |
+| Add a DB query | `infrastructure/database/<domain>_store` |
+| Add a domain event | `domain/<domain>/events` + register in event bus |
+| Add a test | `*_test.go` next to the source file |
+
+### Conventions
+- Error handling: {pattern}
+- Logging: {library + level convention}
+- Config: {env vars / yaml / both}
+- Branch / commit: {convention}
+
+### Gotchas
+- {anything surprising — e.g., "cache TTL is 30s, not 5 min like the comment says"}
+```
+
+### Gate
+- [ ] 1-page mental model written
+- [ ] "Where to find things" table covers ≥5 common tasks
+- [ ] At least 1 gotcha documented (every codebase has them)
+
+---
+
+## Phase 4: GUIDE — first commit checklist
+
+**Goal:** unblock the first real change. The fastest ramp-up is shipping code.
+
+### Pick a "quick win" task
+- ≤30 min change (typo, comment, missing test, small UX nit)
+- Touches one layer only
+- Has a clear success criterion
+
+### First commit checklist
+- [ ] Local env runs: build + lint + tests all green from a fresh clone
+- [ ] Made the change in the right layer (per Phase 3 table)
+- [ ] Added or updated 1 test
+- [ ] Followed naming + error-handling conventions
+- [ ] Commit message matches project style (`git log --oneline`)
+- [ ] PR description follows template (check `.github/PULL_REQUEST_TEMPLATE.md`)
+- [ ] Self-reviewed with `/review:branch` before opening PR
+
+### Who to ask
+- Architecture / "why is it like this": {tech lead from git shortlog}
+- Domain knowledge for area X: {recent committer to that domain}
+- Infra / deploy: {ops contact from README}
+
+### Gate
+- [ ] Local env verified
+- [ ] First "quick win" task picked
+- [ ] First-commit checklist printed
+
+---
+
+## Final Report
+
+```markdown
+## Onboarding Complete: {project}
+
+### Mental Model
+- Stack: {...}
+- Architecture: {...}
+- {N} domains identified
+
+### Output
+- Saved 1-page overview to {path}
+- "Where to find things" table → {path}
+- Gotchas list → {path}
+
+### First Commit
+- Task: {quick-win}
+- Local env: ✅ build / ✅ lint / ✅ tests
+- PR will follow: {project PR template}
+```
+
+---
+
+## Hard Rules
+
+- **Read one module end-to-end before reading 10 partially** — the trace teaches more than skimming
+- **Capture gotchas as you find them** — they vanish from memory in days
+- **First commit ≤30 min** — bigger first changes get rabbit-holed
+- **Don't refactor on day 1** — earn context before changing conventions
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Generate full doc site after onboarding | `/docs:sync` |
+| Build first real 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 pattern |
+| ANALYZE | `@clean-architect` | Layer + boundary analysis |
+| ANALYZE | `@code-reviewer` | Conventions + smell check |
+| ANALYZE | `@security-audit` | Security patterns |
+| EXPLAIN | `@docs-writer` | 1-page overview |
+| GUIDE | `@docs-writer` | First-commit checklist |

package/assets/skills/research/spike/SKILL.md

@@ -0,0 +1,228 @@
+---
+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".
+---
+
+# Spike / Research Workflow
+
+Time-boxed exploration to de-risk a decision by **building** (not just reading). Produces a recommendation + ADR, not production code.
+
+## When to use this skill
+
+- ✅ Need to validate a technical assumption by building
+- ✅ Picking between 2+ options and need real comparison
+- ✅ De-risking a critical path before committing
+- ❌ Want to compare options via docs only → use `/research:web`
+- ❌ Already decided on the approach → use `/feature:new`
+- ❌ Stuck on a known bug → use `/fix:root-cause`
+
+## Read Architecture First
+
+Detect stack via `~/.claude/architecture/_shared/stack-detection.md`. Skim stack doc to understand current patterns — the spike output should fit the architecture or explicitly say why it doesn't.
+
+---
+
+## Workflow
+
+```
+DEFINE → RESEARCH → PROTOTYPE → EVALUATE
+   ↑                                  │
+   └────── timebox expired ───────────┘
+```
+
+---
+
+## Phase 1: DEFINE (15-30 min — never skip)
+
+**Goal:** lock the question, success criteria, timebox. Without these the spike has no exit condition.
+
+### Spike brief
+
+```markdown
+## Spike: {short name}
+
+### Question
+{ONE specific question — answerable yes/no or "pick A vs B vs C"}
+
+### Why now
+{What decision blocks on this answer? When is the decision needed?}
+
+### Options on the table
+- Option A: {name + 1 line}
+- Option B: {name + 1 line}
+- (Option C: only if relevant)
+
+### Success criteria
+- [ ] {Specific, observable — e.g., "P95 latency <50ms at 1k req/s"}
+- [ ] {e.g., "Integration with X library compiles + 1 test passes"}
+- [ ] {e.g., "Estimated migration effort ≤2 sprints"}
+
+### Timebox
+- Quick spike: 2-4 hours
+- Standard: 1-2 days
+- Deep spike: 3-5 days (rare — usually means scope is too big)
+
+### Red flags (stop early if hit)
+- Scope creep into productionising
+- Option requires breaking architecture rules
+- Two options become "obviously the same" after 1 hour
+```
+
+### Gate
+- [ ] Question is ONE specific question
+- [ ] Success criteria are observable (not "feels right")
+- [ ] Timebox + red flags written
+- [ ] User CONFIRMED brief before starting
+
+---
+
+## Phase 2: RESEARCH (≤25% of timebox)
+
+**Goal:** know enough to prototype intelligently, don't over-read.
+
+Run `/research:web` for the topic if you haven't already. Capture:
+
+- Official docs URLs (read, don't just bookmark)
+- Known gotchas / GitHub issues for each option
+- Prior art: anyone tried this combo? what was their conclusion?
+- Constraints from existing stack (versions, license, infra)
+
+### Gate
+- [ ] At least 2 sources per option
+- [ ] Known gotchas listed
+- [ ] Constraints documented
+
+---
+
+## Phase 3: PROTOTYPE (the bulk of the timebox)
+
+**Goal:** build the smallest thing that answers the question.
+
+### Rules
+- **Quick and dirty** — no tests beyond what's needed to verify the question
+- **One option at a time** — full prototype for A, then full prototype for B
+- **In a sandbox** — separate branch, never merge to main
+- **Time-stamped commits** — `spike: A reaches 1k req/s with sync handler` so the timeline is reviewable
+- **Stop on red flag** — if scope creeps or hits a wall, do not push through
+
+### What "smallest" means
+- Skip auth, skip error handling, skip pagination
+- Hardcode config that you'd normally pull from env
+- Stub anything not under test
+- 1-2 happy-path scenarios is enough to verify success criteria
+
+### Stop early when
+- All success criteria met for one option (don't gold-plate)
+- All options fail the same criterion (pivot the question)
+- Timebox 75% used and not converging (something's wrong — stop, regroup)
+
+### Gate
+- [ ] Each option prototyped to the point of answering the question
+- [ ] Success criteria measured (numbers, not vibes)
+- [ ] Findings captured in spike branch commits
+
+---
+
+## Phase 4: EVALUATE
+
+**Goal:** turn the prototype into a recommendation + ADR.
+
+### Comparison matrix
+
+| Criterion | Option A | Option B | Notes |
+|-----------|----------|----------|-------|
+| Success criterion 1 (e.g., latency) | 42ms ✅ | 87ms ❌ | A at 1k rps, B saturates earlier |
+| Success criterion 2 (e.g., effort) | 1 sprint | 3 sprints | B requires new dependency |
+| Fit with architecture | ✅ | ⚠️ Requires port redesign | |
+| Risk | low | medium | B unknowns: lib maturity, no LTS |
+| Team familiarity | high | low | |
+
+### ADR template
+
+```markdown
+# ADR-NNN: {Decision title}
+
+## Status
+Accepted / Superseded / Deprecated
+
+## Context
+{What problem we faced, what alternatives we considered}
+
+## Decision
+{The chosen option}
+
+## Consequences
+**Positive:** {gains}
+**Negative:** {tradeoffs / debt taken on}
+
+## Spike evidence
+{Link to spike branch + key benchmark numbers}
+```
+
+### Cleanup
+- [ ] Spike branch tagged (`spike/{name}-{date}`) so it can be referenced
+- [ ] Spike code NOT merged — production should re-implement properly via `/feature:new`
+- [ ] ADR committed to `docs/adr/` (or equivalent)
+
+### Gate
+- [ ] Comparison matrix filled with real numbers
+- [ ] Recommendation explicit (don't say "both are fine")
+- [ ] ADR written
+- [ ] Spike branch tagged + NOT merged
+
+---
+
+## Final Report
+
+```markdown
+## Spike Complete: {name}
+
+### Question
+{From DEFINE}
+
+### Recommendation
+**Pick Option {X}** because {top reason backed by spike evidence}
+
+### Evidence
+{Benchmark numbers, screenshots, error logs — link to spike branch}
+
+### Next step
+- If accepted: `/feature:new` to build it properly
+- If rejected: document why + close the question
+
+### Time spent
+{Actual vs timebox — note overruns for retrospective}
+```
+
+---
+
+## Hard Rules
+
+- **Define before building** — undefined spike = unbounded spike
+- **Timebox is sacred** — overrun means the question is wrong, not the answer
+- **Throwaway code** — spike branch never merges to main
+- **Numbers, not vibes** — recommendation must cite measurements
+- **One question per spike** — multiple questions = multiple spikes
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Compare options via docs only (no code) | `/research:web` |
+| Spike done, ready to implement properly | `/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 the question |
+| 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 |