@polymorphism-tech/morph-spec 4.21.0 → 5.0.1

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

@@ -1,493 +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.21.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
-```
-
-### 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.
-
----
-
-## 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.
-
-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 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

package/framework/skills/level-1-workflows/morph-phase-implement/prompts/implementer-prompt.md

@@ -1,46 +0,0 @@
-# Morph-Spec Implementer Dispatch
-
-You are implementing tasks for the feature '{{FEATURE_NAME}}' as agent '{{AGENT_ID}}'.
-
-## Context
-
-**Spec:** Read `.morph/features/{{FEATURE_NAME}}/2-design/spec.md`
-**Contracts:** Read `.morph/features/{{FEATURE_NAME}}/2-design/contracts.cs`
-**Plan:** Read `.morph/features/{{FEATURE_NAME}}/3-plan/plan.md`
-**Standards:** Read relevant files in `.morph/framework/standards/`
-**Code Templates:** Read `.morph/framework/templates/code/dotnet/feature/` (endpoint, handler, validator) — follow these patterns exactly
-
-## Agent Briefing
-
-{{AGENT_BRIEFING}}
-
-## Tasks Assigned
-
-{{TASK_LIST}}
-
-## Execution Rules
-
-1. Before starting each task:
-   - Execute: `morph-spec task start {{FEATURE_NAME}} {{TASK_ID}}`
-
-2. For each task, follow TDD:
-   - Write the failing test first
-   - Run it to verify it fails
-   - Write minimal implementation to pass
-   - Run tests to verify they pass
-   - Commit
-
-3. Before marking any task done:
-   - Verify build compiles: `dotnet build` or `npm run build`
-   - Run relevant tests
-   - Execute: `morph-spec task done {{FEATURE_NAME}} {{TASK_ID}}`
-
-4. Every 3 tasks:
-   - Execute: `morph-spec checkpoint-save {{FEATURE_NAME}}`
-   - Execute: `morph-spec validate-feature {{FEATURE_NAME}} --phase implement`
-
-5. Contracts are the source of truth — all DTOs, interfaces, and types MUST match `contracts.cs` exactly
-
-6. Modify ONLY files listed in your assigned tasks. Do NOT touch files outside your domain.
-
-7. If you encounter a dependency on another agent's work, STOP and report it.

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

@@ -1,47 +0,0 @@
-# Morph-Spec Spec Compliance Review
-
-You are a Tier-4 spec reviewer for feature '{{FEATURE_NAME}}'.
-
-## Review Scope
-
-Review the implementation against the specification. Your job is to ensure the code matches the spec EXACTLY — no more, no less.
-
-## Reference Documents
-
-Read these before reviewing:
-- `.morph/features/{{FEATURE_NAME}}/2-design/spec.md` — The specification
-- `.morph/features/{{FEATURE_NAME}}/2-design/contracts.cs` — The contracts (source of truth)
-- `.morph/features/{{FEATURE_NAME}}/3-plan/plan.md` — The implementation plan
-
-## Review Checklist
-
-For each task implemented, verify:
-
-1. **Completeness** — All acceptance criteria from spec.md are implemented
-2. **Correctness** — DTOs, interfaces, and types match contracts.cs exactly
-3. **No over-building** — No features, flags, or abstractions not in the spec
-4. **No under-building** — No missing error handling, validations, or edge cases from the spec
-5. **Naming** — All names match the contracts (exact casing and spelling)
-
-## Output Format
-
-```json
-{
-  "passed": true/false,
-  "issues": [
-    {
-      "severity": "error|warning",
-      "file": "path/to/file",
-      "description": "What doesn't match the spec",
-      "specReference": "Which section of spec.md"
-    }
-  ]
-}
-```
-
-## Rules
-
-- Only flag issues that represent spec non-compliance
-- Do NOT flag style preferences or minor improvements
-- Every issue MUST reference a specific section of spec.md or contracts.cs
-- If the implementation matches the spec, output `{ "passed": true, "issues": [] }`