@polymorphism-tech/morph-spec 4.22.0 → 5.0.1

package/framework/skills/level-1-workflows/morph-phase-implement/SKILL.md

@@ -1,634 +0,0 @@
----
-name: morph-phase-implement
-description: MORPH-SPEC Phase 5 (Implement). Executes feature tasks using TDD with checkpoint validation every 3 tasks, smoke tests via Playwright, and generates code + recap.md. Use after task list approval when starting feature implementation.
-argument-hint: "[feature-name]"
-context: fork
-agent: general-purpose
-user-invocable: false
-cliVersion: "4.22.0"
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Agent
----
-
-# MORPH Implement — Phase 5
-
-> INTERNAL: Workflow skill used by /morph-apply during automated phase orchestration. Not a user command.
-
-Implement the tasks defined in Phase 4, with checkpoints every 3 tasks and a final recap.
-
-## Prerequisites
-
-- [ ] Phase 4 (Tasks) completed
-- [ ] `tasks.md` approved by user
-- [ ] Tasks gate approved (`morph-spec approve $ARGUMENTS tasks`)
-- [ ] All design outputs exist (spec.md, contracts.cs/.ts, decisions.md)
-
-## Step 0: Ensure Implement Phase
-
-**Before any reads or writes — verify the current phase:**
-
-```bash
-morph-spec state get $ARGUMENTS
-```
-
-Check the `"phase"` field:
-
-**If `"phase": "implement"`** → correct phase, proceed.
-
-**If `"phase": "tasks"`** → run in sequence:
-1. `morph-spec state mark-output $ARGUMENTS tasks`
-2. `morph-spec approve $ARGUMENTS tasks`
-3. `morph-spec phase advance $ARGUMENTS` (→ implement)
-
-**Any other value** → STOP — inconsistent state, report to user.
-
-> **Rule:** Never write to `5-implement/` until the phase is `implement`. The hook will block writes.
-
----
-
-## Pre-flight Validation (MANDATORY)
-
-Before any task work, validate that prior phases are truly complete. `state.json` may have been set manually — these commands verify actual filesystem artifacts.
-
-```bash
-# 1. Verify mandatory outputs from all prior phases
-morph-spec validate-feature $ARGUMENTS
-
-# 2. Confirm all approval gates passed
-morph-spec approval-status $ARGUMENTS
-
-# 3. Verify activeAgents are populated
-morph-spec state get $ARGUMENTS | grep -A5 activeAgents
-```
-
-If any check fails → **STOP**. Do not start any task. Report what's missing:
-
-| Problem | Resolution |
-|---------|-----------|
-| Missing output (spec.md, contracts, etc.) | Return to corresponding phase and generate it |
-| Gate not approved (design, plan, tasks) | `morph-spec approve $ARGUMENTS <gate>` |
-| Invalid phase | `morph-spec phase advance $ARGUMENTS` |
-| Empty activeAgents | Run `/phase-setup $ARGUMENTS` first |
-
-**This step is not optional.** Only proceed when all commands return without errors.
-
----
-
-## Pre-flight — Tool Availability
-
-Before starting tasks, verify that CLIs and MCPs needed for this phase are available. The `inject-morph-context` hook reports both at session start.
-
-**1. Check CLIs (from session context `CLIs:` line):**
-
-| CLI | Required for | If missing |
-|-----|-------------|------------|
-| `docker` | Container services (Redis, etc.) | Start Docker Desktop |
-| `neonctl` | Neon database management, migrations | `npm install -g neonctl` |
-| `psql` | Direct DB queries | Install PostgreSQL client |
-| `az` | Azure resource management | `winget install Microsoft.AzureCLI` |
-| `gh` | GitHub PRs, issues | `winget install GitHub.cli` |
-
-If a critical CLI shows `✗`, use `AskUserQuestion` to ask the user:
-- **Install now** — provide the install command
-- **Continue without it** — use fallback (e.g., WebSearch instead of `az`)
-- **Stop implementation** — user must fix and re-run
-
-**2. Check MCPs (from session context `MCPs:` line):**
-
-For each MCP showing `✗ (recommended)`:
-
-| MCP | Fallback |
-|-----|----------|
-| **Context7** | WebSearch + WebFetch |
-| **Playwright** | `curl` / WebFetch (limited — no JS rendering) |
-| **GitHub** | `gh` CLI |
-| **Vercel** | `vercel` CLI |
-
-> **Design:** This check is fail-open — consistent with morph-spec philosophy. Missing tools are warnings, not blockers (except `docker` for container-dependent projects).
-
----
-
-## Scaffold & Code Templates (MANDATORY before first task)
-
-Before writing any implementation code, scaffold the feature structure using the CLI.
-
-### For .NET backend tasks (VSA):
-
-**Scaffold all CRUD slices for the feature:**
-```bash
-morph-spec scaffold dotnet $ENTITY create-$ENTITY
-morph-spec scaffold dotnet $ENTITY get-${ENTITY}-by-id
-morph-spec scaffold dotnet $ENTITY get-all-${ENTITY}s
-morph-spec scaffold dotnet $ENTITY update-$ENTITY
-morph-spec scaffold dotnet $ENTITY delete-$ENTITY
-```
-
-> Entity and errors are generated with the first slice and auto-skipped on subsequent ones.
-> After scaffolding, customize: fill in request/response properties, validation rules, and handler logic per contracts.cs.
-
-### For Next.js frontend tasks:
-
-**Scaffold the feature page:**
-```bash
-morph-spec scaffold nextjs $FEATURE
-```
-
-> After scaffolding, customize: add columns to DataTable, form fields, and Zod schema.
-
-### Template reference (for manual adjustments):
-```bash
-cat .morph/framework/templates/code/dotnet/feature/endpoint.cs.hbs
-cat .morph/framework/templates/frontend/nextjs/page.tsx.hbs
-```
-
-> **Rule:** All code MUST follow the patterns in these templates. Scaffold guarantees this. Do not invent different patterns.
-
-See `.morph/framework/templates/` for the full template index (abstractions, extensions, pipelines, jobs, tests).
-
----
-
-## Recommended Tools
-
-> **Ref:** `framework/skills/level-0-meta/morph-tool-usage-guide/SKILL.md` for complete guide.
-> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` for MCP reference.
-> **Example:** `references/recap-example.md` — filled-in recap.md showing expected output quality.
-
-| Action | Tool | Alternative |
-|--------|------|-------------|
-| Get dispatch recommendation | **Bash** `morph-spec dispatch-agents $ARGUMENTS implement` | Agent recommendations + task routing |
-| **Dispatch implementers by domain** | **Agent** `subagent_type=<recommended[group][0]>` — agent .md file provides the prompt | Backend + frontend + infra in parallel |
-| Read task details | **Read** tasks.md, spec.md, contracts.cs/.ts | — |
-| Create new files | **Write** source files | — |
-| Modify existing files | **Edit** source files | — |
-| Look up library API | **Context7 MCP** `query_docs()` | **WebSearch** + **WebFetch** |
-| Run migrations | **Bash** `dotnet ef database update` | `psql <DB_URL>` for verification |
-| Build project | **Bash** `dotnet build` or `npm run build` | — |
-| Run tests | **Bash** `dotnet test` or `npm test` | — |
-| Checkpoint validation | **Bash** `morph-spec validate-feature ...` | — |
-| Mark task complete | **Bash** `morph-spec task done $ARGUMENTS T001` | — |
-| Smoke test in browser | **Playwright MCP** `browser_navigate()` + `browser_snapshot()` | Manual |
-| Check console errors | **Playwright MCP** `browser_console_messages()` | — |
-| Screenshot for recap | **Playwright MCP** `browser_take_screenshot()` | — |
-| Deploy and logs Vercel | **Vercel MCP** `list_projects()`, `get_deployments()`, `manage_env_vars()` | **Bash** `vercel deploy` |
-| Create PR | **Bash** `gh pr create ...` | **GitHub MCP** `create_pull_request()` |
-| Update state | **Bash** `morph-spec state set ...` | — |
-
-**Phase tools:** Docker CLI (container health, logs), Neon CLI (`neonctl`) (database management), EF Core CLI (migrations), Context7 (API lookup), Playwright (smoke test), GitHub (PRs), Vercel (deploy, logs, env vars).
-
-> **Database Migrations:** When creating or running database migrations, use `dotnet ef migrations add <name>` to create, then `dotnet ef database update` to apply. Verify with `pg_dump $(neonctl connection-string) --schema public` or `psql` against the Neon database (get DB URL from `neonctl connection-string`).
-
-**Anti-patterns:**
-- Task agent for editing a single file (use Edit directly)
-- Subagents for single-domain features (sequential suffices)
-- `Bash cat` to create files (use Write tool)
-- `Bash sed` to modify code (use Edit tool)
-- Implementing without reading contracts.cs/.ts first (contracts are the source of truth!)
-- Running backend and frontend tasks sequentially when they are independent
-- **(VSA)** Creating Application Service layer — handler accesses IRepository directly
-- **(VSA)** Manually registering handlers/endpoints in Program.cs — use auto-discovery via reflection
-- **(VSA)** Placing Request/Response in separate files from Handler
-- **(VSA)** Using `Guid.NewGuid()` — use `Guid.CreateVersion7()`
-- Trying to fix a bug without invoking `systematic-debugging` first
-
-> **Docker CLI:** If a build or test fails with connection errors to local services (Redis, etc.), check container health first: `docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"`. For debugging: `docker logs <container> --tail 50` to see recent logs. To restart a stuck container: `docker restart <container>`.
-
----
-
-## Context Loading
-
-### 1. Read full context in PARALLEL
-
-```
-# Single parallel call, not sequential:
-Read: .morph/features/{feature}/4-tasks/tasks.md
-    + Read: .morph/features/{feature}/2-design/spec.md
-    + Read: .morph/features/{feature}/2-design/contracts.cs  (or contracts.ts for TypeScript projects)
-    + Read: .morph/config/config.json                       (→ architecture.style)
-    + Read: .morph/features/{feature}/3-plan/plan.md
-    + Read: .morph/features/{feature}/1-ui/assets.md              (if exists — image asset specs)
-```
-
-### 2. Detect architecture style
-
-```bash
-cat .morph/config/config.json | grep architecture
-```
-
-If `config.architecture.style === "vertical-slice"` → follow **Step 1.5** before implementing.
-Otherwise → go directly to the task loop.
-
-### Step 1.5: VSA Implementation Guide (only if `style: "vertical-slice"`)
-
-> For the complete slice structure and VSA rules, see `references/vsa-implementation-guide.md`
-
-Structure: `Features/{Entity}Feature/{Op}/` with Handler (+ Request/Response records) + Validator + Endpoint per slice. Everything `sealed`. `Guid.CreateVersion7()`. `result.Match()` in endpoints. No Application Service layer — handler accesses IRepository directly. Auto-discovery via reflection: do not manually register in Program.cs.
-
-### 3. UI Reference Loading (Stitch HTML)
-
-> **Skip if:** `.morph/features/{feature}/1-ui/stitch-screen-map.json` does not exist.
-> This section is OPTIONAL — only applies when the UI/UX phase used Stitch MCP.
-
-If `stitch-screen-map.json` exists, this feature has Stitch HTML exports for visual fidelity:
-
-1. **Read the screen map and CSS mapping in parallel:**
-   ```
-   Read: .morph/features/{feature}/1-ui/stitch-screen-map.json
-   Read: .morph/features/{feature}/1-ui/stitch-html/stitch-css-map.json
-   ```
-
-2. **For each task that modifies a page/route:**
-   - Parse the task description for route references (e.g., `/dashboard`, `/settings`)
-   - Find the matching screen in `stitch-screen-map.json` by route
-   - Read the corresponding HTML file:
-     ```
-     Read: .morph/features/{feature}/1-ui/stitch-html/{screenId}.html
-     ```
-   - Include the HTML in the agent's context along with the CSS mapping
-
-3. **Translation rules for agents:**
-   When implementing from Stitch HTML, agents MUST:
-   - Replace Stitch inline color values with project CSS custom properties using `stitch-css-map.json`
-   - Preserve the **layout structure** (flex/grid hierarchy, element nesting) from Stitch HTML
-   - Preserve **typography hierarchy** (heading levels, font sizes, weights)
-   - Map Stitch HTML elements to the chosen UI library components (e.g., `<div class="card">` → shadcn `<Card>`)
-   - Respect the Stitch spacing proportions, mapping to project spacing tokens
-   - For unmapped values in `stitch-css-map.json`, add them as new tokens to `design-system.md`
-
-> **Source of truth hierarchy:** The Stitch HTML is the visual source of truth. `mockups.md` describes
-> behavior and states; the HTML describes exact visual structure. When they conflict, the HTML wins for
-> layout/visual, mockups.md wins for behavior/states.
-
-### 4. Image Asset Generation (Gemini Image MCP)
-
-> **Skip if:** `.morph/features/{feature}/1-ui/assets.md` does not exist.
-> **Skip if:** Gemini Image MCP is not available.
-> This section is OPTIONAL — only applies when the UI/UX phase created an assets.md spec.
-
-If `assets.md` exists, this feature has image assets to generate during implementation:
-
-1. **Read the assets spec:**
-   ```
-   Read: .morph/features/{feature}/1-ui/assets.md
-   ```
-
-2. **When a task involves a component listed in assets.md:**
-   - Find the matching IMG-NNN entry by component name or route
-   - Invoke `/morph-gemini-image` with the asset spec:
-     - Pass the `Prompt` field as the generation prompt
-     - Pass the `Aspect Ratio` field
-     - Pass the `Output Path` field
-   - If the image needs refinement, use `edit_image` or `continue_editing`
-
-3. **Integrate the generated image into the component:**
-   ```tsx
-   import Image from 'next/image';
-
-   <Image
-     src="/images/{feature}/{name}.png"
-     alt="{descriptive alt text}"
-     width={width}
-     height={height}
-     priority  // if above-the-fold
-   />
-   ```
-
-4. **Verify build compiles** after adding the image reference.
-
-> **Important:** Generate images DURING the task that builds the component, not as a separate step.
-> This keeps the image contextually linked to the component code.
-
----
-
-## Workflow
-
-### Step 0.5: Dispatch Recommendation
-
-Get agent dispatch recommendation:
-
-```bash
-morph-spec dispatch-agents $ARGUMENTS implement
-```
-
-The output is a JSON advisor — it recommends which agents to use and which tasks they handle:
-- `recommended`: `{ [group]: subagentType[] }` — maps groups to agent file names
-- `tasks`: `{ [group]: taskId[] }` — maps groups to task IDs from tasks.md
-- `shouldDispatch`: true if 2+ agents available (parallel dispatch beneficial)
-
-**If `shouldDispatch` is true:**
-
-1. Read `recommended` — maps groups (backend, frontend, etc.) to agent subagentTypes
-2. Read `tasks` — maps groups to task IDs
-3. For each agent, verify `.claude/agents/{subagentType}.md` exists. If missing → **STOP** with: `"Agent file not found. Run: morph-spec setup-infra"`. Do NOT fall back to general-purpose agents.
-4. Dispatch each group in **parallel** using native Agent tool:
-
-```
-Agent(subagent_type="morph-dotnet-senior", prompt="Implement tasks T001, T002 for feature {feature}. Read .morph/features/{feature}/4-tasks/tasks.md for task details and .morph/features/{feature}/2-design/ for contracts and spec. Follow the task loop: start → implement → verify → done. Checkpoint every 3 tasks. Domain isolation: modify ONLY files in your domain.")
-```
-
-> **MANDATORY:** Use the exact `subagentType` value from `recommended`. Do NOT use `general-purpose` agents when a `subagentType` is available.
->
-> The agent `.md` file contains the full expertise prompt, task routing, and key standards. No additional prompt injection needed — just provide the task assignment.
->
-> **If Stitch HTML exists:** When dispatching frontend agents, read `stitch-screen-map.json` and include
-> the relevant screen HTML for each agent's assigned tasks. Populate the `{{STITCH_CONTEXT}}` placeholder
-> in `implementer-prompt.md` with the screen HTML and CSS mapping for the routes that agent is implementing.
->
-> **If assets.md exists:** When dispatching frontend agents, read `assets.md` and include
-> the relevant IMG-NNN entries for each agent's assigned routes. Populate the `{{ASSETS_CONTEXT}}`
-> placeholder in `implementer-prompt.md` with the image specs for the routes that agent is implementing.
-
-5. After all subagents complete, validate integration: `morph-spec validate-feature $ARGUMENTS --phase implement`
-
-**If `shouldDispatch` is false** → continue to sequential task loop (Step 2).
-
-**Fallback:** If `dispatch-agents` fails (non-zero exit or invalid JSON), log a warning and fall back to sequential single-agent mode (Step 2).
-
----
-
-### Step 2: Task Loop
-
-For each task (T001 → T00N):
-
-1. **Start task:**
-   ```bash
-   morph-spec task start $ARGUMENTS T001
-   ```
-2. **Read FR context** (MANDATORY — NON-NEGOTIABLE):
-   - Parse task's `[FR references]` from tasks.md (e.g., `### T001: Create user endpoint [FR001, FR003]`)
-   - **Read spec.md** → the sections for those specific FRs (functional requirements, acceptance criteria)
-   - **Read contracts.cs/.ts** → the DTOs/interfaces referenced by those FRs
-   - The spec is the source of truth. Code that doesn't match the spec is a bug.
-   > **MCP:** Before implementing, use **Context7 MCP** (`resolve-library-id` → `query-docs`) to verify the correct API of the libraries being used. If Context7 is not available, use **WebSearch** + **WebFetch** to check official docs.
-3. **Implement** using Write (new) or Edit (existing)
-4. **Verify** — build, lint, tests
-5. **MANDATORY — Verification before `task done`:**
-   Run `validate-feature` before marking ANY task as done. This is non-negotiable — it catches broken code, missing files, and spec violations before they compound across tasks.
-   ```bash
-   morph-spec validate-feature $ARGUMENTS --phase implement
-   ```
-   Only proceed to step 6 if verification passes. If it fails → fix before marking `task done`.
-6. **Mark as done via CLI:**
-   ```bash
-   morph-spec task done $ARGUMENTS T001
-   ```
-
-### Step 2.5: Scope Escalation (when task is too complex)
-
-If during implementation a task reveals significantly more complexity than estimated:
-
-- **Low impact (1-3 subtasks):** Expand the task directly:
-  ```bash
-  morph-spec task expand $ARGUMENTS T001 --into "T001a: First sub" "T001b: Second sub"
-  ```
-  Then implement each subtask following the same loop above.
-
-- **Medium/High impact (4+ tasks or spec is wrong):** Run the scope escalation workflow:
-  ```bash
-  /morph-scope-escalation $ARGUMENTS
-  ```
-
-**Rule:** Never implement extra functionality within a task without registering it. If a task takes more than expected, expand it into subtasks — this ensures validation gates run for each piece and progress is tracked accurately.
-
-### Step 3: Checkpoint Every 3 Tasks
-
-**After every 3 completed tasks:**
-
-```bash
-# Save checkpoint
-morph-spec checkpoint-save $ARGUMENTS
-
-# Run validation
-morph-spec validate-feature $ARGUMENTS --phase implement
-```
-
-**If validation fails:**
-1. Do NOT advance to the next task
-2. Fix reported issues
-3. Re-run validation
-4. Only then proceed
-
-### Step 4: Test-Driven Development (Recommended)
-
-For each implementation task:
-
-1. **Write test first** (unit test for service/domain)
-2. **Run test** — should fail (RED)
-3. **Implement** the minimum to pass
-4. **Run test** — should pass (GREEN)
-5. **Refactor** if needed (REFACTOR)
-
-```bash
-# .NET
-dotnet test --filter "FullyQualifiedName~{TestClass}"
-
-# Node.js
-npm test -- test/path/to/test.js
-```
-
-### Step 5: Smoke Test with Playwright (if UI)
-
-> **MCP:** After implementing an API endpoint or page, if **Playwright MCP** is available, immediately do a quick smoke test: navigate to the endpoint/page URL, call `browser_snapshot()` to verify it loads, and check `browser_console_messages({ level: 'error' })` for errors. Catch issues while context is fresh rather than waiting for post-implementation. If Playwright is not available, verify manually via `curl` or browser.
-
-After implementing visual components:
-
-```javascript
-// Navigate to the page
-await mcp__playwright__browser_navigate({ url: 'http://localhost:5000/feature-page' });
-
-// Capture page state
-await mcp__playwright__browser_snapshot();
-
-// Check console errors
-await mcp__playwright__browser_console_messages({ level: 'error' });
-
-// Screenshot for recap
-await mcp__playwright__browser_take_screenshot({ type: 'png' });
-```
-
-### Step 5.5: Visual Verification against Stitch (Optional)
-
-> **Skip if:** `.morph/features/$ARGUMENTS/1-ui/stitch-screen-map.json` does not exist.
-> **Skip if:** Playwright MCP is not available.
-> **Skip if:** Dev server is not running.
-> This step is strongly recommended but not blocking — consistent with fail-open philosophy.
-
-After implementing visual components, compare against the Stitch reference:
-
-1. **Load screen map:**
-   ```
-   Read: .morph/features/$ARGUMENTS/1-ui/stitch-screen-map.json
-   ```
-
-2. **For each screen that was implemented in the current task batch:**
-
-   a. **Screenshot the implemented page:**
-      ```
-      mcp__plugin_playwright_playwright__browser_navigate({ url: '{devServerUrl}{route}' })
-      mcp__plugin_playwright_playwright__browser_resize({ width: 1440, height: 900 })
-      mcp__plugin_playwright_playwright__browser_take_screenshot({})
-      ```
-
-   b. **Read the original Stitch screenshot:**
-      ```
-      Read: .morph/features/$ARGUMENTS/1-ui/stitch-screen-{index}.png
-      ```
-
-   c. **Compare visually** (multimodal comparison of both images):
-      - **Layout:** Grid/flex structure matching? Sections in correct positions?
-      - **Typography:** Heading sizes, weights, font families consistent?
-      - **Colors:** Mapped CSS tokens producing visually similar colors?
-      - **Spacing:** Margins and paddings proportionally similar?
-      - **Interactive elements:** Buttons, inputs, cards styled similarly?
-
-   d. **Document results** in `.morph/features/$ARGUMENTS/5-implement/visual-verification.md`:
-      ```markdown
-      # Visual Verification — {feature}
-
-      ## Screen: {title} ({route})
-
-      | Aspect | Match | Notes |
-      |--------|-------|-------|
-      | Layout | ✓/✗ | {notes} |
-      | Typography | ✓/✗ | {notes} |
-      | Colors | ✓/✗ | {notes} |
-      | Spacing | ✓/✗ | {notes} |
-      | Interactive | ✓/✗ | {notes} |
-
-      **Overall:** {PASS/NEEDS_WORK}
-      ```
-
-   e. **If NEEDS_WORK:** Fix the most impactful discrepancies (layout first, then colors,
-      then typography). Re-screenshot and re-compare. Maximum 2 iteration rounds to avoid
-      infinite loops.
-
-3. **Skip gracefully** if any prerequisite is missing (log warning, continue to Step 6).
-
-### Step 6: Generate `recap.md`
-
-After ALL tasks completed:
-
-```bash
-morph-spec generate recap $ARGUMENTS
-```
-
-> For the full recap format, see `references/recap-example.md`
-
-### Step 7: Update State
-
-```bash
-morph-spec state set $ARGUMENTS status done
-morph-spec state mark-output $ARGUMENTS recap
-```
-
-### Step 8: Post-Implementation Review (mandatory before PR)
-
-```bash
-/post-implementation $ARGUMENTS
-```
-
-Run the `post-implementation` skill before creating the PR. It orchestrates:
-- Automated scans (CRITICAL findings block PR)
-- Full test suite
-- Final `validate-feature`
-- Smoke test via Playwright (mandatory if dev server active)
-- Code review checklist (CRITICAL + HIGH)
-- **`morph-checklist`** — compliance (security, SEO, performance, accessibility, LGPD)
-- Checkpoint + final recap
-
-### Step 9: Frontend Review (NEXTJS/FULLSTACK)
-
-If stack is NEXTJS or FULLSTACK:
-
-```bash
-/frontend-review $ARGUMENTS
-```
-
-Complements `post-implementation` with: accessibility scan (static + axe-core runtime),
-responsive screenshots (mobile/tablet/desktop), and SEO metadata verification.
-
----
-
-## Morph-Native Dispatch
-
-morph-spec uses its own agents and validators for implementation, dispatch, and review.
-
-### Implementation
-
-Get dispatch recommendation and use native Agent tool:
-```bash
-morph-spec dispatch-agents $ARGUMENTS implement
-```
-
-Use `recommended[group]` subagentTypes directly:
-```
-Agent(subagent_type="morph-dotnet-senior", prompt="Implement tasks T001, T002 for feature X...")
-```
-
-> Agent `.md` files are self-contained — they include the expertise prompt, task routing, and key standards. The `subagentType` maps to `.claude/agents/` filenames:
-> - Tier 1-3: `morph-{id}` (e.g., `morph-dotnet-senior`)
-> - Tier 4: `morph-validator-{id}` (e.g., `morph-validator-architecture-expert`)
-
-### Review (Two-Stage)
-
-**Stage 1 — Spec Compliance (mandatory):**
-```
-Agent(subagent_type=<validator subagentType>, prompt=<filled prompts/spec-reviewer-prompt.md>)
-```
-Use validators from `dispatch-agents --mode validate`. Spec compliance MUST pass before proceeding.
-
-**Stage 2 — Code Quality (mandatory):**
-```
-Agent(subagent_type=morph-standards-architect, prompt=<filled prompts/code-quality-reviewer-prompt.md>)
-```
-`critical` issues block. `important` issues must be fixed. `suggestion` is optional.
-
-### Prompt Templates
-
-| Template | Usage |
-|----------|-------|
-| `prompts/implementer-prompt.md` | Dispatch to implementer agents |
-| `prompts/spec-reviewer-prompt.md` | Spec compliance review |
-| `prompts/code-quality-reviewer-prompt.md` | Code quality review |
-
----
-
-## Outputs
-
-- Implemented source code (various files)
-- Unit and integration tests
-- `.morph/features/$ARGUMENTS/5-implement/recap.md` — Implementation summary
-
-## Completion Criteria
-
-- [x] All tasks completed
-- [x] Build compiles without errors
-- [x] Tests passing
-- [x] Validation pipeline passes
-- [x] `recap.md` generated
-- [x] State updated to `status: done`
-- [x] Checkpoints saved every 3 tasks
-- [x] `/post-implementation` executed without BLOCKs
-
----
-
-## Phase Outputs
-
-<!-- morph-outputs:implement -->
-| Output | Caminho |
-|--------|---------|
-| `recap` | `.morph/features/{feature}/5-implement/recap.md` |
-<!-- /morph-outputs -->
-
----
-
-## Relevant Standards
-
-During implementation, standards auto-load via rules when editing relevant file types.
-For proactive reference:
-- Architecture: `.morph/framework/standards/architecture/` — structural compliance
-- Backend/Frontend: `.morph/framework/standards/backend/` or `.morph/framework/standards/frontend/`
-- Security: `.morph/framework/standards/security/` — authentication, authorization patterns
-- Testing: follow the project's existing test patterns (check `test/` or `tests/` directory)
-
----
-
-Feature complete! Consider creating a PR and running `morph-spec generate recap $ARGUMENTS`.

package/framework/skills/level-1-workflows/morph-phase-implement/prompts/code-quality-reviewer-prompt.md

@@ -1,50 +0,0 @@
-# Morph-Spec Code Quality Review
-
-You are the standards-architect reviewer for feature '{{FEATURE_NAME}}'.
-
-## Review Scope
-
-Review the implementation for code quality, architecture compliance, and adherence to project standards.
-
-## Reference Documents
-
-Read these before reviewing:
-- `.morph/context/standards.md` — Project coding standards
-- `.morph/context/README.md` — Project architecture overview
-- `framework/standards/` — Framework-level standards (reference as needed)
-
-## Review Checklist
-
-1. **Naming Conventions** — PascalCase for types, camelCase for variables, kebab-case for files (or as defined in standards)
-2. **Architecture Compliance** — Code follows the project's VSA architecture pattern (Handler + Validator + Endpoint per feature folder)
-3. **Async Patterns** — CancellationToken propagated, no fire-and-forget, proper await
-4. **Error Handling** — Appropriate exceptions, no swallowed errors, consistent patterns
-5. **Security** — No hardcoded secrets, SQL injection, XSS vectors, or OWASP top 10 issues
-6. **DI Lifetimes** — Correct service registration (Scoped for DB, Singleton for config, etc.)
-7. **Test Quality** — Tests follow Arrange-Act-Assert, meaningful assertions, no test duplication
-
-## Output Format
-
-```json
-{
-  "passed": true/false,
-  "issues": [
-    {
-      "severity": "critical|important|suggestion",
-      "file": "path/to/file",
-      "line": 42,
-      "description": "What the issue is",
-      "fix": "How to fix it"
-    }
-  ]
-}
-```
-
-## Rules
-
-- `critical` issues MUST be fixed before merge
-- `important` issues SHOULD be fixed
-- `suggestion` issues are optional improvements
-- Only `critical` issues cause `passed: false`
-- Be specific — always include file path and line number
-- Prefer minimal fixes over refactoring